Re: [boost] Boost Development Environment proposal

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2007-06-04 12:41:47

"Beman Dawes" <bdawes_at_[hidden]> wrote in message 
news:f3uemn$sa2$1_at_sea.gmane.org...
> There is a fresh draft of a Boost Development Environment proposal up at
> http://mysite.verizon.net/beman/development_environment.html

Hi, Beman.

The proposal is the move in a right direction. There are some "issues" with 
it IMO:

1. Overly formal notion of "stable" branch

>From what I understand the proposal goes long length making sure there is a 
stable branch. On the way several "procedures" are introduced, which require 
some discipline from developers, new scripts to be written developed and 
manual development branch test requests to be submitted.

2.  "Half baked" notion of dependency

On a way the proposal refer to some library dependencies. It's unclear how 
they are supported, checked and enforced. For example if author of library A 
is ready to move his dev branch to stable, how can we make sure this change 
won't break library B that depends on it. And if it is who is  at fault?

3. There is no support for partial/independent release (at least in 
policies)

4. No ability to test against particular branch of dependant library A.

I believe most (all?) of the problem can be resolved with solution I 
proposed soon before BoostCon: 
http://article.gmane.org/gmane.comp.lib.boost.devel/158491

I see Troy pitching similar idea for directory structure in other post in 
this chain so I won't repeat it. Let me just say that I implemented this 
approach while ago in my make system I use at work and it was worth all the 
efforts.

My solution formalize notion of independent components with their 
independent versions and the dependency in between them. The only tough spot 
is "stable" umbrella release combination. The algorithm for it might require 
some fine tuning but it's clear how it should work. Essentially for every 
library A that changed from version N1 to version N2 you find version N3: N1 
<= N3 <= N2, so that all libraries that depends on A were releases against 
that version. I can come up with formal algorithm description if there is an 
interest.

Couple answers on possible questions:

* To request testing against particular releases of dependencies you just 
change your Jamfile to point to them.
* To release your own library developer doesn't need to do anything single 
snv copy command will do. Jamfile will include version of all the 
dependencies. (Optionally svn externals can be used to simplify pulling 
particular subset of boost even more)
* No testing required during release. Once umbrella boost release is 
combined it follows strait to packaging.

The way I see it, we have almost all we need to implement this. If snv 
externals work (and some people tell me they don't) we may not need to make 
any changes in make system (by creating reflection of split by lib tree into 
combined tree).

Gennadiy