Re: [boost] Boost Development Environment proposal

From: Beman Dawes (bdawes_at_[hidden])
Date: 2007-06-03 18:02:23

Edward Diener wrote:
> 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.

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.

> 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.

Thanks for the comments. The issue of how to identify versions of 
subsets needs further discussion for sure.

--Beman