Between Three And Six What?

The other way the project can lower tensions around release planning is to make releases fairly often. When there’s a long time between releases, the importance of any individual release is magnified in everyone’s minds; people are that much more crushed when their code doesn’t make it in, because they know how long it might be until the next chance. Depending on the complexity of the release process and the nature of your project, somewhere between every three and six months is usually about the right gap between releases, though maintenance lines may put out micro releases a bit faster, if there is demand for them.

— Karl Fogel, Producing Open Source Software

2 thoughts on “Between Three And Six What?

    • I should clarify, I suppose: that sounds about right to me for point releases, which concentrate mostly on bug fixes and maybe a few new features. You do, of course, have to assume at that frequency that the overwhelming majority of users will skip releases, upgrading from 2.8 to 3.2 or whatever, as suits their schedule. But the development cycle has to take more things into consideration than just when the users are all going to upgrade.

      Major user-visible changes, especially big sweeping UI changes, should generally not be made in point releases but held for major releases, which should be roughly every 3-6 years in most cases. (UI changes that only impact users of a new feature don’t count here, though. Those can go into point releases for a couple of years after the new feature first lands.)