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