[boost] Re: 1.32 release preparation

From: David Abrahams (dave_at_[hidden])
Date: 2004-06-28 10:52:46

"Robert Ramey" <ramey_at_[hidden]> writes:

>>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.  

Did you miss this part?

  Schedule

  Development on our main branch will proceed in three stages. Each
  stage will be two months in length.

  Stage 1

  During this period, 
  changes of any nature may be made to the compiler.

I think they are willing to destabilize the main trunk at least
during stage 1.

> 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 don't think there's any way we can do a release _today_, even with
no new libraries ;-)

> 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.

First of all, a new version of MPL is the main motivation for this
particular release, so we _are_ going to merge it in from its
development branch (mplbook) before the trunk branches for release.
Secondly, a core library like MPL may occasionally change its
interface in ways that are not strictly backwards-compatible.  If
development of other libraries continues while MPL is on its branch,
it may be unreasonable to expect MPL's branch to ever work with all
those libraries' trunk state.  At some point, you have to check it in
and let the other libraries adjust.

I like the idea of keeping the trunk healthy -- that's the way I
always try to operate -- but I don't think that branching for release
without warning or communication is reasonable, and I think you have
to occasionally be willing to have major changes to core libraries
moved to the trunk before you can guarantee that it will cause no
trunk breakage.  Boost is a collaborative effort, and we rely on
communication and cooperation.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com