Proposal -------- * Quarterly release schedule, with the target release date the 15th of the first month of each quarter. * If a release is late, that does not slip the date of the next quarter's release. * If something isn't ready for the current release, it is simply held until the next release. The current release is not delayed. * Being ready means being ready by the cutoff date set by the release manager. That will be relative early in the release cycle. Rationale --------- Regular releases that occur on a predictable schedule have many benefits: * Developers know far in advance when library updates must be ready, and that's both an aid to planning and a motivation to get stuff done. * Users know far in advance when library updates will be ready, and that helps their planning and reassures them of continuing support. * Regularity creates a sense of quality and trust in Boost for both developers and users. Quarterly releases seem about right: * It's often enough that the process will become smooth. * It's often enough that developers won't feel pressure to release immature updates. * It's often enough that users will feel bug fixes and new libraries are being released on a timely basis. * It isn't so often that users will view Boost as unstable, particularly given the predictable schedule. * It isn't so often that developers and release managers will become fatigued. * A quarterly (or similar) schedule has been very successful for both open source and commercial projects. Comments? The rationale depends a lot on my personal experiences, but I don't see that as a bad thing. --Beman
on Thu Aug 23 2007, Beman Dawes <bdawes-AT-acm.org> wrote:
Proposal --------
* Quarterly release schedule, with the target release date the 15th of the first month of each quarter.
* If a release is late, that does not slip the date of the next quarter's release.
* If something isn't ready for the current release, it is simply held until the next release. The current release is not delayed.
* Being ready means being ready by the cutoff date set by the release manager. That will be relative early in the release cycle.
I would like to add that it means having all necessary documentation in place. A library whose code is ready but whose documentation is not complete and up-to-date is not ready.
Rationale ---------
Regular releases that occur on a predictable schedule have many benefits:
* Developers know far in advance when library updates must be ready, and that's both an aid to planning and a motivation to get stuff done.
* Users know far in advance when library updates will be ready, and that helps their planning and reassures them of continuing support.
* Regularity creates a sense of quality and trust in Boost for both developers and users.
Quarterly releases seem about right:
* It's often enough that the process will become smooth.
* It's often enough that developers won't feel pressure to release immature updates.
* It's often enough that users will feel bug fixes and new libraries are being released on a timely basis.
* It isn't so often that users will view Boost as unstable, particularly given the predictable schedule.
* It isn't so often that developers and release managers will become fatigued.
* A quarterly (or similar) schedule has been very successful for both open source and commercial projects.
Comments? The rationale depends a lot on my personal experiences, but I don't see that as a bad thing.
Looks good to me. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com
participants (2)
-
Beman Dawes -
David Abrahams