Beman Dawes wrote:
There is a fresh draft of a Boost Development Environment proposal up at http://mysite.verizon.net/beman/development_environment.html
This is a very well thought-out piece. I see one minor problem with it: it depends on additional work from the developers, namely, explicit merge requests. I'm afraid that the principle of least resistance will result in work happening on -devel and -stable stagnating due to lack of merge requests. In a non-volunteer ogranization one will have the authority and means to enforce the procedures and prevent this, but I'm not sure about Boost. That said, it might be good time for us to radically rethink the structure of Boost and decouple versions from releases. Versions should be per-library, and releases should be a set of versions. This separation ought to be enforced on a directory tree level, as in: boost/ foo/ foo.hpp bar/ bar.hpp with nothing else allowed in boost/. A separate compat/ directory would hold the current contents of boost/ (header name-wise), giving people a migration path. This should probably come with a stricter dependency management approach than the current "none". Each library should list its dependencies, per-library tests should operate on a subtree formed by the dependencies and not on the full boost/ tree, adding an additional dependency should be frowned upon. We might consider introducing "dependency levels" such that a level N library can depend on level N-1 libraries, but not vice versa. With this organization, several releases can proceed in parallel, it being the sole responsibility of the release manager to pick the correct library subset and their versions such that the result is a stable release. More importantly, it allows developers to concentrate on improving their libraries. Once there one could venture into the direction that packaging a specific release should be the job of the installer and not of the release manager; that is, Boost should package individual library versions, not a monolithic .34.zip. The installer probably ought to also allow upgrading a single library (or adding a new library) should the user so choose.