Re: [boost] Boost Development Environment proposal

From: Edward Diener (eldiener_at_[hidden])
Date: 2007-06-03 21:37:13

Beman Dawes wrote:
> 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.

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.