Beman Dawes wrote:
There is a fresh draft of a Boost Development Environment proposal up at http://mysite.verizon.net/beman/development_environment.html
Here are some suggestions to promote the idea that individual Boost libraries can be released between full releases of the entire Boost set of libraries, as relating to your item "It is reasonably easy to release of subsets of Boost." These suggestions are admittedly all given from this end-user's perspective, rather than a Boost developer's perspective , but the suggestions are well-meant and are not given to be a burden on Boost developers. 1) For all libraries a main header file should contain a release number in some human readable format, such as "Boost XXX Version 1.34". This is purely for the purpose of the end-user knowing which version of a subset he has. 2) For non-header only libraries, versioning should be used to generate appropriate version resources for each shared library being produced. This allows shared libraries to be installed using normal installation packaging programs, such as Installshield, Wise, Microsoft Install itself, as well as providing the end-user the appropriate information about the library. I do realize that libraries are normally encoded with these numbers but I still feel the internal versioning, when it exists for an operating system, should also be used as appropriate, especially as Boost Build allows end-users to turn off the encoding of library names by their versions. 3) Any subset release of a Boost library should contain a package which incorporates all subset dependencies. This ensures that any dependencies of the subset are always distributed with their latest working changes when the subset is distributed. Theoretically one would not need to do this if the dependency had not changed since the last full release, so perhaps this could be relaxed, but I see confusion in distributing subsets with such dependencies in determining if any changes had occurred in the dependencies, as well as confusion on the end-user's part in determining to which release the subset should be installed. In this way, after a major Boost release, such as 1.34, subsets can be released as necessary for downloads as packages with numbers like 1.34.1 on up etc., or, if Boost sees itself reserving intermediate numbers such as that between releases, 1.34.0.1 on up etc. These suggestions are made for a number of reasons. First the enormous time between release 1.33.1 and 1.34 meant many C++ programmers were eagerly awaiting the next release for a long time. Secondly when a serious bug is found after a full Boost release, it may be appropriate to do a subset release to get that bug fixed appropriately and in the hands of as many end-users as possible through normal release channels ( as opposed to CVS and now Subversion, where many organizations will not go for stability reasons ). Finally when a particular subset of Boost has major work done and tested, and end-users are eagerly waiting for the improvements to that subset, that subset can be released as a point release off of a full Boost release. I do realize that Boost developers may not want to look at the releasing of subsets of the full Boost distribution as a viable means to distribute Boost, since a mismatched subset of a particular library with its dependencies can easily lead to end-user headaches unless it is done very carefully. But I think that Boost should look seriously at reducing the monolithic structure of its distribution as a greater number of library are added in the future, and I am very glad Beman Dawes at least suggested this in his paper.