>
> 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
(text/plain)