Re: [boost] Boost Development Environment proposal

From: Edward Diener (eldiener_at_[hidden])
Date: 2007-06-03 10:36:23

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.