Beman Dawes wrote:
Edward Diener 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
Beman Dawes wrote: 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.
That's tricky. A file in a subset release won't necessarily correspond exactly to any version of that file that appears in a full Boost release.
The form of a subset release which I am envisioning has to be some "change" off of a full Boost release, and there needs to be some method of identifying that. I say that because an end-user should be able to "install" a subset release on top of the directory structure which he has for a given release of Boost and everything will continue to work as expected. Furthermore it might sound ambitious but I can well imagine that a subset release may have more than one release off of a major Boost release, so that identifying each time that happens is important. These are the reasons that I think it is imperative to have some form of human readable and understandable versioning which can identify each subset release for the end user as related to a Boost full release.
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.
I a little out of my depth here. Troy Straszheim has been working with a big project on his day job that does subset releases, and we are trying to leverage his experience, along with other Boosters who have similar experience. Perhaps some of these folks could comment on version numbering for subsets.
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.
Yes. I've been running under the assumption that "Any subset release of a Boost library should contain a package which incorporates all subset dependencies."
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.
My assumption is that some of the larger sub-groups within Boost (Spirit, for example) might want to release subsets, and we should be doing what we can to enable that. OTOH, I'm not seeing the full Boost group doing subsets, at least in the foreseeable future.
My suggestion is that any Boost library, if the situation were important enough, could create a subset release between full Boost releases. This would solve the problem which seems to occur quite often in Boost where new features, or serious bug fixes, for a particular library, is constrained to wait for a full Boost release, and the full Boost release is heavily delayed because of the huge amount of effort necessary to have everything regression tested and co-ordinated. The idea of a subset release for a particular library and its dependencies may add more complexity to Boost distributing itslf but it changes the monolothic nature whereby all of Boost must be ready to be released, or none of it gets released. As more libraries are added to Boost, I see such a rigid methodology as an impediment to a more flexible way of developing and distributing Boost. However this is essentially up to the Boost developers to decide. But I think it is important to consider that certain libraries may want to get out changes and innovations which are valuable from the end-user's point of view without waiting for the next full release. Since I am an end-user and not a Boost developer I wish Boost good luck in considering such changes.