Re: [boost] 1.34 Release Plan - an alternative view

From: Robert Ramey (ramey_at_[hidden])
Date: 2006-01-25 12:39:54

I understand that as boost gets bigger it gets harder to make
new releases.  There is more to do, more to keep in sync,
and more ripple effect in changes.  I see this more structured
and formal release procedure as an attempt to deal with this.
It seems to aim for a closer coordination of developement
and release efforts to avoid difficulties associated with
development of software libraries which have varying
degrees of coupling.  I sympathize with with the effort.

I would summarize the general idea as getting developers
more "in sync" through different stages of development
and release.  I see this as getting more difficult as boost
gets bigger and more diverse.  The development of different
libraries can't really be "scheduled".

So I think this is the wrong approach and I think it will
make things harder rather than easier.

I would propose a different way of going about this.  Here
it is.

For the moment, exclude those packages related to
building and testing from consideration - I'll address
those at the end.

a) developers build and test their libraries on their local machine
against the latest release.

b) when they think they are ready, they open a branch on the
main trunk and check in their "next release".  So the cvs
system will have a branch for every developers "next release"

c) when checked in - the developer will queue up a test request
on the new branch.

d) when the the test results show that the "next library release"
is "ready",  the branch is merged with the main trunk.  The
complete regression test is then run.  There "should" be no new
errors but there might be cases where the library developer has
inadvertently changed some undocumented behavior which
might show us as some error.  Also there might be cases where
the other parts of boost detect an error which has not been
detected in the library test suite.  These should be only a few
cases.

e) Once tests a d) above pass, the boost library version is incremented
and a new release is emitted.

f) At this point, working developers would update their local development
copies of the CVS tree.

In this system:

a) Each library could be developed at its own pace an schedule.  There would
be not rush to "make the next release" with all the problems that that 
causes.

b) The latest release of Boost would more up to date.  That is, one wouldn't
be in the situation of needing the next ehancemet, knowing its already in 
there
but not being able to use it because the next release isn't ready yet.

 c) Testing resources would be used much more efficiently.  Basically
more testing would be focused on areas that are likely to have problems
and less testing is focused on things that "almost for sure" should pass.
Testing would be done only where and when changes have been made.

Code  for building and test are special cases and would have to be
considered individually.  Certainly Jamfile/toolset updates could
be work with the above system.  Movement to V2 wouldn't fit here
and would have to be considered how to do this.  Boost.Test enhancement
would require some consideration as well.  In general - code breaking
changes would have to be considered specially.

Basically, I don't believe the current Boost developement model is
scalable and I think the procedure has to change to recognise this.
So in my view the current proposal goes in exactly the wrong
direction.

Note that this is starting to occur by necesity.  Multi-index has a "beta"
version compatible with 1.33 that one can download.  I've been
testing changes to serialization on my machine against 1.33.  I haven't
checked them into the HEAD.  So now I know what problems are
mine and what problems are associated with changes in compiler
versions, stlport versions etc.  My next step is to make a few more
changes, run some more tests locally (basically later version of stlport)
and upload a package similar to Joaquin's.  This would make the
changes (mostly bug fixes and documentation upates) available
to those who need them now and also give those who want to help
me out a way to test my changes without waiting for the next release
when it will be too late to fix anything.

Robert Ramey