The release branch (https://svn.boost.org/svn/boost/branches/release) is open for merging all stable changes from trunk, including bug fixes and major upgrades to existing libraries. Breaking changes should be coordinated via the mailing list with the developers of the other libraries affected. New libraries may be added, but require permission of a release manager. In other words, except for new libraries, merging changes *does not* need permission from a release manager. I.e. just do it! The release schedule is more aggressive than usual on the front end so that we can maintain our quarterly release schedule: * September 13, 2009: branches/release closed for new libraries and breaking changes to existing libraries. Still open for bug fixes and other routine changes to all libraries. * September 20, 2009: Release managers start QA checks. * October 4, 2009: branches/release closed for major code changes. Still open for serious problem fixes and docs changes. * October 11, 2009: branches/release closed for all library changes except when specific permission given by release manager(s). * October 18, 2009: Beta release target date. Further betas and/or release candidates as feedback dictates. * November 1, 2009: Release ship date. Links relating to this release: * Google Calendar with the release schedule: <http://www.boost.org/development/index.html>. * Release schedule explanation: <http://svn.boost.org/trac/boost/wiki/ReleaseSchedule>. * Release practices for developers: <http://svn.boost.org/trac/boost/wiki/ImprovingPractices>. -- The release managers
Hmmm - might we change the release schedule policy from "every three months" to "three months after the previously release" ? It would seem more sensible to me since the time between last merge to the shipping has been reduced to a couple of weeks. The important thing is for uses to know that if he has a problem and reports it (and maybe nags about it) he might get a fix in the next 3 months. BTW - Is there a consensus that this release procedure is a huge improvement over the previous one? What are the current obstacles to making it easier? Robert Ramey Beman Dawes wrote:
The release branch (https://svn.boost.org/svn/boost/branches/release) is open for merging all stable changes from trunk, including bug fixes and major upgrades to existing libraries. Breaking changes should be coordinated via the mailing list with the developers of the other libraries affected. New libraries may be added, but require permission of a release manager.
In other words, except for new libraries, merging changes *does not* need permission from a release manager. I.e. just do it!
The release schedule is more aggressive than usual on the front end so that we can maintain our quarterly release schedule:
* September 13, 2009: branches/release closed for new libraries and breaking changes to existing libraries. Still open for bug fixes and other routine changes to all libraries.
* September 20, 2009: Release managers start QA checks.
* October 4, 2009: branches/release closed for major code changes. Still open for serious problem fixes and docs changes.
* October 11, 2009: branches/release closed for all library changes except when specific permission given by release manager(s).
* October 18, 2009: Beta release target date. Further betas and/or release candidates as feedback dictates.
* November 1, 2009: Release ship date.
Links relating to this release:
* Google Calendar with the release schedule: <http://www.boost.org/development/index.html>.
* Release schedule explanation: <http://svn.boost.org/trac/boost/wiki/ReleaseSchedule>.
* Release practices for developers: <http://svn.boost.org/trac/boost/wiki/ImprovingPractices>.
-- The release managers _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Thu, Sep 3, 2009 at 12:27 PM, Robert Ramey<ramey@rrsd.com> wrote:
Hmmm - might we change the release schedule policy from "every three months" to "three months after the previously release" ? It would seem more sensible to me since the time between last merge to the shipping has been reduced to a couple of weeks. The important thing is for uses to know that if he has a problem and reports it (and maybe nags about it) he might get a fix in the next 3 months.
Since 1.40.0 was almost a month late, I did consider scheduling 1.41.1 three months from ship date. While there weren't any killer reasons for not doing that, there were several softer arguments in favor of keeping to the regular schedule: * Experience in the past (on another project) with keeping to a quarterly schedule even if one quarter slipped seemed to show that there were less schedule slips if the quarterly schedule was maintained. Perhaps there was less tendency to slip if it meant having to catch up next quarter. * The current schedule, particularly for the November and February 1st target dates, fits well with US holidays and personal commitments I have every year. It is very hard for me (and a lot of other folks) to schedule anything between mid-November and Mid-January, and March/April also tend to have a lot of commitments for me.
BTW - Is there a consensus that this release procedure is a huge improvement over the previous one?
It is a huge improvement from my viewpoint:-)
What are the current obstacles to making it easier?
I'll try to address that in a separate message. Thanks, --Beman
From our perspective as long-time Boost users, the new release schedule is much more palatable and better supports our production development cycles. Boost has made tremendous strides in its adoptability just because of the quarterly release heartbeat. Our compliments to everyone involved in making this work so well over the last several releases: I know this take a lot of attention and dedication to pull off well. Just a brief comment, I agree that "every 3 months" is a better ideal (an ideal ideal?), in part because it counters longer than intended release cycles and helps assure that the average cycle is quarterly even if it must reasonably be missed now and again. Plus short cycles after long (and presumably more involved) cycles help make sure valuable "maintenance oriented" occasionally occur. Thanks again, Richard ---------- Richard Newman richard@cdres.com On 9/4/2009 8:58 AM, Beman Dawes wrote:
On Thu, Sep 3, 2009 at 12:27 PM, Robert Ramey<ramey@rrsd.com> wrote:
Hmmm - might we change the release schedule policy from "every three months" to "three months after the previously release" ? It would seem more sensible to me since the time between last merge to the shipping has been reduced to a couple of weeks. The important thing is for uses to know that if he has a problem and reports it (and maybe nags about it) he might get a fix in the next 3 months.
Since 1.40.0 was almost a month late, I did consider scheduling 1.41.1 three months from ship date. While there weren't any killer reasons for not doing that, there were several softer arguments in favor of keeping to the regular schedule:
* Experience in the past (on another project) with keeping to a quarterly schedule even if one quarter slipped seemed to show that there were less schedule slips if the quarterly schedule was maintained. Perhaps there was less tendency to slip if it meant having to catch up next quarter.
* The current schedule, particularly for the November and February 1st target dates, fits well with US holidays and personal commitments I have every year. It is very hard for me (and a lot of other folks) to schedule anything between mid-November and Mid-January, and March/April also tend to have a lot of commitments for me.
BTW - Is there a consensus that this release procedure is a huge improvement over the previous one?
It is a huge improvement from my viewpoint:-)
What are the current obstacles to making it easier?
I'll try to address that in a separate message.
Thanks,
--Beman _______________________________________________ Unsubscribe& other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (3)
-
Beman Dawes -
Richard Newman -
Robert Ramey