At the BoostCon '08 "Future of Boost" session there was discussion of release schedules, and we took a straw poll. Thanks to Hartmut Kaiser for recording the outcome: ○ How often do we want to have Boost releases? § 4 weeks: 0 § 6 weeks: 0 § 8 weeks: 10 votes § 12 weeks: 25 votes § 16 weeks or longer: 6 votes Since 12 weeks was already the target we had discussed on the list, that seems pretty well decided as our target. Dave Abrahams suggested that specific target dates be assigned; that makes the targets more specific and easier to plan around. I suggest the last day of the first month of each quarter: * January 31 * April 30 * July 31 * October 31 The last day is chosen rather than the first day, because January 1st comes after a holiday period in which it is hard to get anything done. So working backwards from the target date, T, what are the key milestones, and the time to perform the tasks involved? * Ship release / update web sites * Release candidate(s) - 7 days * Beta release(s) - 14 days * Freeze release except for showstoppers - 7 days * Freeze release except for bug fixes - 14 days * Release open for bug fixes, major library upgrades, and new libraries - As soon as prior release is done. In other words, the three month cycle looks like this: |-------6 weeks--------|--2 weeks--|-1 wk-|--2 weeks--|-1 wk-| | | | | | | | new libs, | fixes | show | beta(s) | RC's | | upgrades, | | stop-| | | | fixes | | pers | | | The times alloted to each activity are fairly arbitrary - we would adjust as we build experience. Comments? --Beman
--------------------------- Vicente Juan Botet Escriba ----- Original Message ----- From: "Beman Dawes" <bdawes@acm.org> To: "Boost Developers Mailing List" <boost@lists.boost.org> Sent: Wednesday, May 21, 2008 10:18 PM Subject: [boost] Release schedule?
At the BoostCon '08 "Future of Boost" session there was discussion of release schedules, and we took a straw poll. Thanks to Hartmut Kaiser for recording the outcome:
○ How often do we want to have Boost releases? § 4 weeks: 0 § 6 weeks: 0 § 8 weeks: 10 votes § 12 weeks: 25 votes § 16 weeks or longer: 6 votes
Since 12 weeks was already the target we had discussed on the list, that seems pretty well decided as our target.
Dave Abrahams suggested that specific target dates be assigned; that makes the targets more specific and easier to plan around. I suggest the last day of the first month of each quarter:
* January 31 * April 30 * July 31 * October 31
The last day is chosen rather than the first day, because January 1st comes after a holiday period in which it is hard to get anything done.
So working backwards from the target date, T, what are the key milestones, and the time to perform the tasks involved?
* Ship release / update web sites * Release candidate(s) - 7 days * Beta release(s) - 14 days * Freeze release except for showstoppers - 7 days * Freeze release except for bug fixes - 14 days * Release open for bug fixes, major library upgrades, and new libraries - As soon as prior release is done.
In other words, the three month cycle looks like this:
|-------6 weeks--------|--2 weeks-- |-1 wk- |--2 weeks-- |-1 wk-| | | | | | | | new libs, | fixes | show | beta(s) | RC's | | upgrades, | | stop- | | | | fixes | | pers | | | The times alloted to each activity are fairly arbitrary - we would adjust as we build experience.
Comments?
--Beman _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
----- Original Message ----- From: "Beman Dawes" <bdawes@acm.org> To: "Boost Developers Mailing List" <boost@lists.boost.org> Sent: Wednesday, May 21, 2008 10:18 PM Subject: [boost] Release schedule?
At the BoostCon '08 "Future of Boost" session there was discussion of release schedules, and we took a straw poll. Thanks to Hartmut Kaiser for recording the outcome:
○ How often do we want to have Boost releases? § 4 weeks: 0 § 6 weeks: 0 § 8 weeks: 10 votes § 12 weeks: 25 votes § 16 weeks or longer: 6 votes
Since 12 weeks was already the target we had discussed on the list, that seems pretty well decided as our target.
Dave Abrahams suggested that specific target dates be assigned; that makes the targets more specific and easier to plan around. I suggest the last day of the first month of each quarter:
* January 31 * April 30 * July 31 * October 31
The last day is chosen rather than the first day, because January 1st comes after a holiday period in which it is hard to get anything done.
So working backwards from the target date, T, what are the key milestones, and the time to perform the tasks involved?
* Ship release / update web sites * Release candidate(s) - 7 days * Beta release(s) - 14 days * Freeze release except for showstoppers - 7 days * Freeze release except for bug fixes - 14 days * Release open for bug fixes, major library upgrades, and new libraries - As soon as prior release is done.
In other words, the three month cycle looks like this:
|-------6 weeks--------|--2 weeks--|-1 wk-|--2 weeks--|-1 wk-| | | | | | | | new libs, | fixes | show | beta(s) | RC's | | upgrades, | | stop-| | | | fixes | | pers | | | The times alloted to each activity are fairly arbitrary - we would adjust as we build experience.
Comments?
Hello, If I have undesrood, next release *could* be on 31 july. Which will its containt? * The new libraries that have been make an explicit their intention and are ready to be on the release 6 weeks before, i.e. 19 juin; Why not start already a request for new libraries inclusion, we have just a month? What does it means "have been make explicit their intention and are ready to", could be subjet to interpretation of the release manager, but an explicit request will be welcom. * the upgrades done 3 weeks before, i.e. the 10 july. * the critical fixes up to the 31 july (Of course the release manager will be impled on which fgixes are critical and which one can be done for the next release. These seams quite good to me. Note that * nothing critical should be included after 10 July. * libraries not ready before 10 juin should be posponed to the next releasean so rejected for includsion from the 1.36 release This was just some precision on the dates and the contents view from my desk. Have a good 1.36 release! _____________________ Vicente Juan Botet Escriba
vicente.botet wrote:
----- Original Message ----- From: "Beman Dawes" <bdawes@acm.org> To: "Boost Developers Mailing List" <boost@lists.boost.org> Sent: Wednesday, May 21, 2008 10:18 PM Subject: [boost] Release schedule?
...
If I have undesrood, next release *could* be on 31 july. Which will its containt? * The new libraries that have been make an explicit their intention and are ready to be on the release 6 weeks before, i.e. 19 juin;
Yes, new libraries would have to be merged into branches/release by June 19.
Why not start already a request for new libraries inclusion, we have just a month?
Yes, but I wanted to get feedback first.
What does it means "have been make explicit their intention and are ready to", could be subjet to interpretation of the release manager, but an explicit request will be welcom. * the upgrades done 3 weeks before, i.e. the 10 july. * the critical fixes up to the 31 july (Of course the release manager will be impled on which fgixes are critical and which one can be done for the next release.
Yes.
These seams quite good to me.
Note that * nothing critical should be included after 10 July. * libraries not ready before 10 juin should be posponed to the next releasean so rejected for includsion from the 1.36 release
This was just some precision on the dates and the contents view from my desk.
In other words, here is how the schedule would play out for this release: June 19 - branches/release closed for new libraries and major upgrades or breaking changes to existing libraries. July 3 - branches/release closed for routine minor changes and fixes. Still open for serious problem fixes. July 10 - branches/release closed for all library changes except where specific permission given by release manager(s). July 15 (sooner if possible) Beta 1 target date. Continue to release betas and/or release candidates as feedback dictates. July 31 Release target date.
Have a good 1.36 release!
Thanks, --Beman
2008/5/21 Beman Dawes <bdawes@acm.org>:
* Ship release / update web sites * Release candidate(s) - 7 days * Beta release(s) - 14 days * Freeze release except for showstoppers - 7 days * Freeze release except for bug fixes - 14 days * Release open for bug fixes, major library upgrades, and new libraries - As soon as prior release is done.
At the moment release is the basis for a possible 1.35.1 which suggests that it isn't open for major changes yet. Will point releases be based on another branch? Daniel
Daniel James wrote:
2008/5/21 Beman Dawes <bdawes@acm.org>:
* Ship release / update web sites * Release candidate(s) - 7 days * Beta release(s) - 14 days * Freeze release except for showstoppers - 7 days * Freeze release except for bug fixes - 14 days * Release open for bug fixes, major library upgrades, and new libraries - As soon as prior release is done.
At the moment release is the basis for a possible 1.35.1 which suggests that it isn't open for major changes yet. Will point releases be based on another branch?
Yes. That way work on a point release won't delay work on the next regular release. --Beman
participants (3)
-
Beman Dawes -
Daniel James -
vicente.botet