Message: 16 Date: Sun, 27 Jun 2004 22:25:47 -0500 From: "Aaron W. LaFramboise" <aaronrabiddog51@aaronwl.com> Subject: Re: [boost] Re: 1.32 release preparation To: boost@lists.boost.org Message-ID: <40DF8FBB.4040408@aaronwl.com> Content-Type: text/plain; charset=us-ascii Aaron W. LaFramboise wrote:
Robert Ramey wrote:
Dave Abrahams wrote:
I'd like to know the reasons for "all the sudden rush". We did announce a schedule long ago, and it has already been delayed by three weeks. I'm not asking in order to point fingers; I just want to know how to avoid the "sudden rush" next time.
Here is the current scenario.
a) The announcement gets posted - release 1.32 scheduled for date x. b) Each developer decides - uh oh I better get in my changes before date x. c) Of course these changes take longer d) and break some other things e) which takes longer still
Personally I think the concept of scheduling a release fundamentally flawed. I would suggest another idea.
As an observer, I'm fairly impressed with GCC's release methodology. http://gcc.gnu.org/develop.html
A critical component is a schedule that includes several stages during which certain sorts of changes are unacceptable.
There's still rush, but most of the rush for major features or other destabilizing elements happens long before the release comes around.
I found this to be very interesting. I had never seen this before. It basically implements my view that the "Main Line" should be code that is always works and is ready to be used, tested and potentially released. As far as I'm concerned it's totally consistent with my proposal which I thought was un-orthodox but now see that is used at least by GCC. So, my view would be - stick to the original 28 June date, require that new libraries be added to branches and merge to main as appropriate. I realize its not THAT easy - but it would address the concerns that I have about the whole process and allow all libraries to proceed on independent schedules. New libraries would be tested against the "known good tree" independently of one another. Take as a small example changes in MPL. The current method is to check in a new version of MPL and see what happens. Presumable some issues will arise and now we have a broken system which inhibits development of other libraries until the issues are resolved. Under the proposed method, the new MPL would be check in under its own branch and issues would be detected on all libraries before they affect other developers. Anyway - my 2 cents. Robert Ramey