"Beman Dawes" <bdawes@acm.org> wrote in message news:f3uemn$sa2$1@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