Re: [boost] Independent Libraries Versioning proposal

From: Nicola Musatti (Nicola.Musatti_at_[hidden])
Date: 2007-06-11 12:31:13

Robert Ramey <ramey <at> rrsd.com> writes:
[...]
> The essence of Beman's proposal is:
> 
> a) maintain a releasable (stable) version.
> b) do developement on branches - one branch per development project.

OK, but how? I'm not a subversion expert, but as far as I can tell the
following is a reasonable description of what we're facing.

If you branch the whole of Boost, developers will have to perform merges each
time they want to update their sandbox. These may be inexpensive in terms of
repository disk space, but are a much greater PITA than sandbox updates.

Otherwise you have to keep into account the fact that Subversion branches
influence your directory structure. Branching only the library specific parts
with the current structure leads to one of the following alternatives:

A - Branch from top level with empty intermediate levels:

boost
 +branches
   +SERIALIZATION_BRANCH
     +boost
     | +serialization
     +libs
       +serialization

B - Branch as low down as possible:

boost
 +boost
 | +serialization
 |   +branches
 |     +SERIALIZATION_BRANCH
 +libs
   +serialization
     +branches
       +SERIALIZATION_BRANCH

None of these allow checking out with a single command, unless you resort to
heavy use of svn:externals. In this situation the alternative structure that
several people propose seems more in line with most of the proposed process
changes.

> c) Test against the releasable version.
> d) Once a development project has been successfully tested against the the
> releasable version
>     i) merge the development project into the releaseable version.
>     ii) retest the whole releaseable version
>     iii) automatically regenerate a deliverable package

Again, how? The notion of a single library test queue requires a form of tool
support we currently don't have and even if we had it, I'm not convinced it
would be easy to make this scheme work given the current type of
discretionary, voluntary testing we have. On the other hand unless additional
resources are found there's little else that can be done, apart from a little
rationalization and, certainly, fixing the current tools.

> This is totally orthogonal to proposals to making independent
> library versions, changing the source control system, etc.

I believe I've shown that this is not entirely true, at least as far as
version control is concerned. I agree that single library versioning, however
desirable, is a different matter.

> We should try to change one thing at a time.  I would suggest
> do the following in sequence and embarking on one thing only
> after the previous one has been digested.
> 
> a) move to SVN - which seems already underway.
> b) implement to Beman's test/release proposal
> c) consider changes required to support independent library
> versioning.

I still think that what I suggest here:
http://svn.boost.org/trac/boost/wiki/AlternateProcessProposal
is close to the minimum change we must apply if we want things to take a
different turn in 1.35 .

Cheers,
Nicola Musatti