Re: [boost] Boost Development Environment proposal

From: troy d. straszheim (troy_at_[hidden])
Date: 2007-06-04 11:39:19

On Mon, Jun 04, 2007 at 05:37:13PM +0300, Peter Dimov wrote:
> 
> As I said in my other post - which hasn't generated much interest - I think 

Very strong interest from me, at least.  

> that we're at a point where the lock-step approach is no longer feasible; 
> that is, we can no longer afford to avoid versioning libraries by way of 
> pretending that the leading 1. in front of the release number makes it a 
> version.
> 
> Put differently, what I'm saying is that Boost can no longer pretend to be a 
> library instead of a compilation.

CPAN is interesting to compare to.  It is a dependency-managing
download-build-test-install system.  Such a thing is way out of scope
for boost right now, but for CPAN it works well.

> A release should merely be a collection of library versions that have been 
> tested together and known to work.
> 
> In terms of SVN structure this could look like:
> 
> trunk/
>   boost/
>     foo/
>     foo.hpp
>     bar/
>     bar.hpp
>   libs/
>     foo/
>     bar/
> 
> versions/
>   foo-1.0/
>     boost/
>     libs/
>   foo-1.1/
>   foo-2.0/
>   bar-1.0/
>   bar-2.0/
> 
> releases/
>   r35/
>     boost/
>     libs/
> 
> but of course other arrangements are possible.

See my other post in this thread; if you keep headers and src
together, they're easier to manage in svn.  Also you can assemble a
release (simply a list of library versions to be assembled and built
together) via a list of svn:externals:

boost_1_34_0:
iostreams  https://svn.boost.org/svn/boost/iostreams/releases/x
date_time  https://svn.boost.org/svn/boost/date_time/releases/y
function   https://svn.boost.org/svn/boost/function/releases/z

which are versioned in the repository, branchable, mergable, etc.  For
instance, I could svn cp this boost_1_34_0 directory to my area in the
sandbox and tweak it:

boost_mybranch:
iostreams  https://svn.boost.org/svn/boost/iostreams/releases/x
date_time  https://svn.boost.org/svn/boost/date_time/releases/y
function   https://svn.boost.org/svn/boost/function/releases/z
newlib     https://svn.boost.org/svn/sandbox/newlib/releases/w
mylib      https://svn.boost.org/svn/sandbox/mylib/branches/something

> The benefit of this approach is decentralization. The maintainer of foo only 

It can be decentralization to the point of chaos.  Some policy is
necessary to get the releases out the door, but of course the release
manager is not hamstrung by the fact that the repository organization
won't allow (her)him to do what (s)he needs to do...

> modifies trunk/boost/foo, trunk/libs/foo and creates versions/foo-* when 
> he's satisfied with the test results on the trunk. The release manager of 
> r35 only copies library versions from versions/ to releases/r35, does 
> whatever needs to be done to resolve test failures by nagging the 
> maintainers to fix bugs in foo-2.0 creating foo-2.1 (and failing that picks 
> 1.1 instead), and ships when he's satisfied with the test results on r35. 
>
> It's clear who can commit, where, and when, and a release doesn't block 
> development. It's even possible for r36 to appear before r35. :-)

-t