Presently, the team at Websystems is in the final stages of getting AceProject 4.5 ready to release. We are testing the new system as much as we can, so we can release as bug-free a system as we can. However, we also know there is a one-month period after the version release, where we will be correcting details dug up by our users. As much as we know AceProject and as much as we test it before release, there is nothing like thousands of users to find a few bugs we overlooked. 

In the end, it's the calssic case of being too close to the tree to see the forest. There are as many ways to use AceProject as there are users, and it is simply impossible for us to replicate how each user navigates the system and uses the features.  The whole release process is very impredictable. At Websystems, we never committed to a specific date for a new release version.

Sure, we have an idea of when the new version will be released. It usally starts with a season. For example, for AceProject 4.5, we knew we would release it in the Spring of 2008. As the process of developing the new version gets closer to the end, we can narrow it down to a month. For AceProject, we are confident version 4.5 will be out in April. However, we never decide on a date before the actual release is published. 

So much can happen between the day we choose a date and the due-date itself. Someone can get sick and thow off the schedule, a new feature can be trickier to  implement, or a bug could take longer than expected to diagnose and fix. When is the last time you saw a company release its software on the planned date? It seems to me setting a specific date is inviting problems.

It all comes down to what is the most important: being on time, or being ready?