Re: [boost] Release plans [was: Maintenance release?]

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-05-05 17:52:43

In light of the proposed release schedule below, I think we should
consider what needs to be done to get Boost.Build (v1) in shape. I
realize we have placed a moratorium on v1 development, but I think it
would be appropriate to make an exception for some ease-of-use fixes.

My list of what's important:

1. Change all configuration variables representing paths to names
which end in "_PATH". This eliminates "spaces in pathnames" problems
since Jam won't split these except at path separators (':' on *nix,
';' on windows).

2. Set these variables as neccessary from variables with the old names
for backwards-compatibility

3. Add comments about how to configure the toolset (see gcc-tools.jam).

4. When configuration is detectably wrong, print a helpful message
about how to configure the toolset (see msvc-stlport-tools.jam). This
should be extended to take advantage of the GLOB rule if it is
defined, though we have to be careful to release precompiled jams
which support new features before we do anything which requires
them. The GLOB rule can be used to look for the compiler in the PATH,
for example.

5. Possible low-cost replacement for 3&4: implement a
--help-<toolset-name> option for each toolset which dumps
configuration instructions.

Thoughts?

----- Original Message -----
From: "Beman Dawes" <bdawes_at_[hidden]>

> At 06:28 PM 4/30/2002, David Abrahams wrote:
> >Hi All,
> >
> >Boost 1.27 contained bugs of various sorts which are causing me to
> >have to answer lots of "why won't this build?!?" questions. In
> >particular, the threads lib had a problem with extern "C" linkage
> >which is causing a failure for lots of people. The Python lib also
> >had problems on a few compilers. Naturally, users blame the build
> >system. At the same time, the reliability of Boost.Build has been
> >considerably improved, and it now gives helpful hints for building
> >the python library (which also helps those who want to build the
> >rest of boost and don't care about Python).
> >
> >Aside from those problems which are costing time and energy, we
> >have a new mailing list archive, newsgroups have been activated,
> >and other improvements have been made. The website has not been
> >updated to reflect this, though some of the CVS html has been. Not
> >having up-to-date information available to the public causes an
> >additional drain on our resources. I would like to make a
> >maintenance release quickly, before we move to a
> >more... contemplative... release process.
>
> I think we should go ahead with a release of whatever is ready.
> Since there is at least one new library, the release would be 1.28.0
>
> I agree we need a release real soon now. So I'd like to suggest not
> merging in "unit_test_development" for this release, because it is
> bound to cause weeks of delay getting regression tests running again
> on all platforms.
>
> But as we discussed in Curacao, shock therapy may be needed for
> "unit_test_development", so after this upcoming release we should do
> the merge right way to start people focusing on finding and fixing
> the problems.
>
> So here is the schedule I suggest:
>
> Now until Release - Run "old" Win32 regression test
daily
> Now until Wednesday, May 8th - Finish any pending changes
> Wednesday, May 8th - Branch for release
> Thursday, May 9 - Tuesday, 14th - Fix regression failures
> Wednesday, May 15 - Target release date
> Thursday, May 16 - Merge "unit_test_development"
> Thursday, May 16 on - Get the "new" regression tests
working