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.