>
> As for any consideration for a variable release cycle, I think that too
> often leads to drawn out development cycles with pent up features and more
> bugs.  Schedules (and budgets, if we had one), force decision making.  They
> ensure that important features do not get hung up on unimportant ones.  By
> setting a goal(deadline), we make it much easier to decide or at least
> force the decision making process.  Does this mean that every release will
> come out on time.  No.  Groovy is a good example of this.  However, when we
> fail to meet a deadline we feel that pain, improve and move on to the next
> release.
>
> **
>

This seems compelling to me, especially given the distributed nature of
development that we have.  On reflection, I think that an ad-hoc release
cycle might run the risk of leaving packages behind; if there isn't a
well-specified deadline to work to and there are hard decisions to be made
(as Shaun suggests), it might lead to some developers not having time to
get ready for a release.  At least, if there's a well-specified, regular
release cycle, you see the train coming from a long way down the track.

-- Bill