Re: [boost] Independent Libraries Versioning proposal

From: Robert Ramey (ramey_at_[hidden])
Date: 2007-06-11 15:03:01

Nicola Musatti wrote:
> 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.

Personally, I have no problem with branching the directories and
files related to my project - even if they can't be done with a single
command.  I don't think this would require any change in directory
structure with either CVS or SVN.

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

true.

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

That would depend upon how it was implemented.
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.

The resources dedicated to testing would be much less than now so more 
effective
testing could be done.  That is this system would test only
that which would benefit from testing - much, much less that the
current approach.

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

Well, we have to disagree here.

> I agree that single library
> versioning, however desirable, is a different matter.

Agree.

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

I skimmed your document and:

a) I don't believe that beman's proposal requires changing the directory
tree structure.
b) I don't believe that bemans proposal requires a change to SVN.

But my main object is that it is "top down" in that is imposes more
rules and structure on the testing/release procedure.  I think that our
current problems stem from the same approach.  I think that the system
has to be designed to permit more flexibility - not less which I think
is what Beman's proposal does.

>
> Cheers,
> Nicola Musatti
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost