[1.48.0] Proposed Release Schedule
Give we are already in the middle of July, I feel strongly 1.48.0 should target the first Monday in November, thus putting us back on our usual quarterly cycle. In our earlier schedule discussion, there was some interest in a three times a year release schedule, but the arguments were not convincing to me, so I really think we should keep to our quarterly schedule. The current formula for intermediate dates goes like this: * One week after prior release ships: branches/release opens for merging all stable changes, including bug fixes, and major upgrades to existing libraries. Breaking changes should be coordinated with libraries affected. New libraries may be added with permission of a release manager. * Seven weeks before release: branches/release closed for new libraries and breaking changes to existing libraries. Still open for bug fixes and other routine changes to all libraries. * Six weeks before release: QA checks on snapshot doc builds, inspect status, getting started guide, and install. * Four weeks before release: branches/release closed for major code changes. Still open for serious problem fixes and docs changes. * Three weeks before release: branches/release closed for all library changes except when specific permission given by release manager(s). * Two weeks before release: Beta target date. Further betas and/or release candidates as feedback dictates. I propose that the Beta be scheduled for *Four* weeks before the release target date. All the other intermediate dates would thus be two weeks earlier. That's more or less what we did for 1.47.0 and it allowed enough time to fix a bunch of bugs in the beta that were bothering users. --Beman
On Wednesday, July 13, 2011 08:16:09 AM Beman Dawes wrote:
Give we are already in the middle of July, I feel strongly 1.48.0 should target the first Monday in November, thus putting us back on our usual quarterly cycle. In our earlier schedule discussion, there was some interest in a three times a year release schedule, but the arguments were not convincing to me, so I really think we should keep to our quarterly schedule.
The current formula for intermediate dates goes like this:
* One week after prior release ships: branches/release opens for merging all stable changes, including bug fixes, and major upgrades to existing libraries. Breaking changes should be coordinated with libraries affected. New libraries may be added with permission of a release manager. * Seven weeks before release: branches/release closed for new libraries and breaking changes to existing libraries. Still open for bug fixes and other routine changes to all libraries. * Six weeks before release: QA checks on snapshot doc builds, inspect status, getting started guide, and install. * Four weeks before release: branches/release closed for major code changes. Still open for serious problem fixes and docs changes. * Three weeks before release: branches/release closed for all library changes except when specific permission given by release manager(s). * Two weeks before release: Beta target date. Further betas and/or release candidates as feedback dictates.
I propose that the Beta be scheduled for *Four* weeks before the release target date. All the other intermediate dates would thus be two weeks earlier.
That's more or less what we did for 1.47.0 and it allowed enough time to fix a bunch of bugs in the beta that were bothering users.
Sounds very good to me! What are the chances of having a 1.47.1 point release?
--Beman
On 13 July 2011 13:16, Beman Dawes <bdawes@acm.org> wrote:
The current formula for intermediate dates goes like this:
* One week after prior release ships: branches/release opens for merging all stable changes, including bug fixes, and major upgrades to existing libraries. Breaking changes should be coordinated with libraries affected. New libraries may be added with permission of a release manager.
I think it'd be a good idea to ask on the list what's planned for the next release, mainly for new libraries but also incoming changes to existing libraries.
* Seven weeks before release: branches/release closed for new libraries and breaking changes to existing libraries. Still open for bug fixes and other routine changes to all libraries.
If this is brought forward by 2 weeks, it will become 9 weeks before release, which seems a bit tight. A release cycle lasts from 12 to 14 weeks. We open the release branch after 1 week, so that leaves 2 to 4 weeks, which can be significantly reduced if the previous release was late, or there's a point release. Keeping it at 7 weeks, or maybe 8, would be better IMO.
* Six weeks before release: QA checks on snapshot doc builds, inspect status, getting started guide, and install.
Does anyone actually observe this one? I tend to check the documentation for new libraries as they're added, and then the whole of the documentation much later.
Beman Dawes [bdawes@acm.org] wrote:
Given we are already in the middle of July, I feel strongly 1.48.0 should target the first Monday in November, thus putting us back on our usual quarterly cycle. In our earlier schedule discussion, there was some interest in a three times a year release schedule, but the arguments were not convincing to me, so I really think we should keep to our quarterly schedule.
The current formula for intermediate dates goes like this:
* One week after prior release ships: branches/release opens for merging all stable changes, including bug fixes, and major upgrades to existing libraries. Breaking changes should be coordinated with libraries affected. New libraries may be added with permission of a release manager. * Seven weeks before release: branches/release closed for new libraries and breaking changes to existing libraries. Still open for bug fixes and other routine changes to all libraries. * Six weeks before release: QA checks on snapshot doc builds, inspect status, getting started guide, and install. * Four weeks before release: branches/release closed for major code changes. Still open for serious problem fixes and docs changes. * Three weeks before release: branches/release closed for all library changes except when specific permission given by release manager(s). * Two weeks before release: Beta target date. Further betas and/or release candidates as feedback dictates.
That's seven weeks for release, possibly longer based upon extending the beta period, plus one week of release branch being frozen following a release. 8 * 4 = 32. 52 - 32 = 20. 20 / 4 = 5 weeks between releases now.
I propose that the Beta be scheduled for *Four* weeks before the release target date. All the other intermediate dates would thus be two weeks earlier.
Two weeks is tight, but adding two might be overkill. You don't want to lose momentum or urgency by allowing too much time. 10 * 4 = 40. 52 - 40 = 12. 12 / 4 = 3 weeks between releases with a four week beta period. I think that justifies releases thrice per year. That also makes point releases less intrusive on subsequent release cycles. _____ Rob Stewart robert.stewart@sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
Beman Dawes wrote:
Give we are already in the middle of July, I feel strongly 1.48.0 should target the first Monday in November, thus putting us back on our usual quarterly cycle. In our earlier schedule discussion, there was some interest in a three times a year release schedule, but the arguments were not convincing to me, so I really think we should keep to our quarterly schedule.
I would like to again advocate for a release cycle not tied to a specific frequency. Currently, the time between release n and n+1 is determined by the time that it takes release n to get cleaned up. In an extreme case where this time were to stretch to 8 weeks, there wouldn't be any time between release n and n+1. So I would prefer the release rule to be release n+1 is 12 weeks after n. Also, I'm (again) offering the suggestion that the periodic testing be altered so that a library X on the trunk is tested againts the current state of the libraries on the release branch (that is the NEXT release). I believe this would have a number of benefits - including the streamlining of the release process. It would also speed up the testing itself since the release branch changes less frequently so there would be fewer dependencies for each test. This would require a change in the testing scripts - but not a huge one. FWIW, this is the testing that I do on my own machine so that it isolates my errors from any changes do to unknown/unexpected changes in other libaries. So I know from personal experience that this is an improvement. Robert Ramey
on Wed Jul 13 2011, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
Beman Dawes wrote:
Also, I'm (again) offering the suggestion that the periodic testing be altered so that a library X on the trunk is tested againts the current state of the libraries on the release branch (that is the NEXT release). I believe this would have a number of benefits - including the streamlining of the release process. It would also speed up the testing itself since the release branch changes less frequently so there would be fewer dependencies for each test. This would require a change in the testing scripts - but not a huge one. FWIW, this is the testing that I do on my own machine so that it isolates my errors from any changes do to unknown/unexpected changes in other libaries. So I know from personal experience that this is an improvement.
Robert, I'm with you on this. It's one of the things we're doing with Ryppl. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On 7/13/2011 11:32 AM, Robert Ramey wrote:
Also, I'm (again) offering the suggestion that the periodic testing be altered so that a library X on the trunk is tested againts the current state of the libraries on the release branch (that is the NEXT release).
I'm all for that model of testing. But..
I believe this would have a number of benefits - including the streamlining of the release process. It would also speed up the testing itself since the release branch changes less frequently so there would be fewer dependencies for each test.
Hm, I'm not sure that's true. It's certainly true if you are isolating the testing for each library and doing each incrementally. But that's a lot of Boost checkouts to maintain (or some complicated include managing)... Of course I'm only talking about the current Boost file structure.
This would require a change in the testing scripts - but not a huge one.
I certainly welcome patches to make this possible, and reasonable for testers. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
Rene Rivera wrote:
On 7/13/2011 11:32 AM, Robert Ramey wrote:
Also, I'm (again) offering the suggestion that the periodic testing be altered so that a library X on the trunk is tested againts the current state of the libraries on the release branch (that is the NEXT release).
I'm all for that model of testing. But..
I believe this would have a number of benefits - including the streamlining of the release process. It would also speed up the testing itself since the release branch changes less frequently so there would be fewer dependencies for each test.
Hm, I'm not sure that's true. It's certainly true if you are isolating the testing for each library and doing each incrementally.
I think that's what I'm advocating.
But that's a lot of Boost checkouts to maintain (or some complicated include managing)... Of course I'm only talking about the current Boost file structure.
And this is the rub. On my own personal system it's not a problem of course since I have have a complete copy of the release branch on my system - EXCEPT that for the serialization library I have the trunk version. In order to implement this for the testers, something equivalent to the following would be necessary. For each library X which has changed on the trunk Rename library X directories on "release" to "previous release" Rename library X trunk directories to release Run bjam tests Reverse steps 2 and 1 above. I'm not specifically advocating this as an an implementation method - I'm just describing a logically correct method of what I would like to see. The SVN system does have a "switch" comand from changing directories in one's local tree - but it merges (not what I want) and it takes forever. Maybe GIT users want to chime in here - this might be just the incentive to get "over the hump" in convincing those of luddites who hate messing with our tools to get on board the GIT bandwagon.
This would require a change in the testing scripts - but not a huge one.
I certainly welcome patches to make this possible, and reasonable for testers.
Robert Ramey
El 13/07/2011 14:16, Beman Dawes escribió:
* One week after prior release ships: branches/release opens for merging all stable changes, including bug fixes, and major upgrades to existing libraries. Breaking changes should be coordinated with libraries affected. New libraries may be added with permission of a release manager.
Is release branch open now for new libraries (Boost.Move)? Best, Ion
2011/7/20 Ion Gaztañaga <igaztanaga@gmail.com>:
El 13/07/2011 14:16, Beman Dawes escribió:
* One week after prior release ships: branches/release opens for merging all stable changes, including bug fixes, and major upgrades to existing libraries. Breaking changes should be coordinated with libraries affected. New libraries may be added with permission of a release manager.
Is release branch open now for new libraries (Boost.Move)?
Yes. Haven't had a chance to post the formal notice, sorry. --Beman
El 20/07/2011 23:29, Beman Dawes escribió:
2011/7/20 Ion Gaztañaga<igaztanaga@gmail.com>:
El 13/07/2011 14:16, Beman Dawes escribió:
* One week after prior release ships: branches/release opens for merging all stable changes, including bug fixes, and major upgrades to existing libraries. Breaking changes should be coordinated with libraries affected. New libraries may be added with permission of a release manager.
Is release branch open now for new libraries (Boost.Move)?
Yes. Haven't had a chance to post the formal notice, sorry.
Thanks! Ion
Is release branch open now for new libraries (Boost.Move)? Yes. Haven't had a chance to post the formal notice, sorry. So, when the release branch will be closed for the new libraries? I
21.07.2011 1:29, Beman Dawes пишет: propose to update the release schedule at http://www.boost.org/development/index.html. -- Sergey Cheban
From: Sergey Cheban <s.cheban@drweb.com> To: boost@lists.boost.org Sent: Wednesday, July 27, 2011 1:59 PM Subject: Re: [boost] [1.48.0] Proposed Release Schedule
Is release branch open now for new libraries (Boost.Move)? Yes. Haven't had a chance to post the formal notice, sorry. So, when the release branch will be closed for the new libraries? I propose to update the release schedule at http://www.boost.org/development/index.html.
2nd on that I'd like to know how much does it left to merge new libraries? Is it possible to provide a schedule with dates not "weeks from/to" some point. Thanks! Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.sf.net/ CppDB - C++ SQL Connectivity: http://cppcms.sf.net/sql/cppdb/
On 27 July 2011 12:13, Artyom Beilis <artyomtnk@yahoo.com> wrote:
2nd on that I'd like to know how much does it left to merge new libraries?
Is it possible to provide a schedule with dates not "weeks from/to" some point.
Thanks!
There wasn't any conclusion to the discussion, but under Beman's proposal the closing date for new libraries is 9 weeks before the proposed release date. Since no one suggested it should be earlier, that's a safe target for merging new libraries. It works out as 5th September, if there aren't any other responses today, I'll add it to the calendar.
participants (10)
-
Artyom Beilis -
Beman Dawes -
Daniel James -
Dave Abrahams -
Ion Gaztañaga -
Rene Rivera -
Robert Ramey -
Sergey Cheban -
Stewart, Robert -
Thomas Heller