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