Scott James Remnant described problems with a mixed milestone-and-date release process as it applies to Ubuntu GNU/Linux.
The specific problem is that each milestone represents a date by which you absolutely must finish your work lest you have to wait for the next milestone. In one sense, that's a feature of regular release cycles: if a feature isn't ready for the current release, it can wait until the next release. In practice, uncautious project management can turn this virtue into a vice in two ways:
- If you get rewarded or punished based on meeting or missing calendar dates—not the appropriate level of release quality—you will prioritize calendar time over quality.
- If the periodicity between releases is too great, you'll prioritize getting a project in the current release over waiting until the next release.
Choosing the right periodicity is more art than science. (Project management is art, not science.) Yet you can know the period length is inappropriate when the end of a period approaches and you suffer the great stampede of features suddenly becoming good enough to land the week or weekend or day before your cutoff date for features landing for the next Great Big Release.
You can see the evolution of this understanding in Parrot over the past couple of years. (It wasn't enough to save Parrot, but no technical policy can prevent active malice from untrustworthy committers.) Whereas Parrot promised to adhere to a six month cycle of publishing a deprecation or incompatible change notice before making the change or removal, that promise was simply untenable as waiting six months to make necessary changes left no one happy, least of all the end user implementors for whom the policy should have been most useful. That big stampede happened in Parrot as every six month cycle closed.
When Parrot switched to a three month period, the big stampede still happened.
When I'm fortunate enough to work within a dedicated team of full-time developers using an agile approach, an iteration period of a week or two often seems to work the best. Anything longer than that still has stampedes, but delaying a branch merge by a week or so to get another day or two of polish isn't a big deal. Delaying a branch merge by a month or so pushes the edge of what's acceptable.
Granted, releasing stable and useful software still requires a lot of discipline from project management and developers. Slashdot comment screeching to the contrary, shorter release cycles don't have to mean that Unity-style big bang UI changes will land every month. (I suspect that Unity could have used another few months of development and testing and integration, if not another six month cycle). It's also often a simple matter of programming to release a feature present but disabled by default so as to get more testing on deployment and integration without forcing users to siwtch yet.
Yet the most important matter of discipline is unambiguous and ubiquitous project status information such as the reports from automated test suites, memory leak checkers, branch status reports, bug reports, and anything else that can measure the quality of the iteration's eventual release.
Certainly this requires a substantial investment on the part of projects to build and maintain this infrastructure, but it's the only reliable and repeatable way I know to produce great software. (If you've noticed that Perl's monthly bleadperl releases are rather boring, that's the point! Most of the excitement takes place at project boundaries such as the interactions with CPAN modules.)
