From: Christian Larsen (contact_at_[hidden])
Date: 2008-08-25 17:03:49
Beman Dawes skrev:
> Daniel Wallin wrote:
>> It that's the case then that problem won't go away by releasing patches
>> rather than point releases; they still need testing.
> But the patch testing occurs on trunk and branches/release. We are
> already testing those, so no additional testing, reporting, or admin
> effort is required.
If regression testing is already being performed on both trunk and
branches/release, I don't see why you would not want to do something
like what I proposed here:
Back then the reason for not doing it this way was testing obstacles,
but if both trunk *and* a release branch are tested, I don't see the
problem. It is just a matter of switching which release branch is tested
once for each major release. I.e. now testing should be performed on
trunk and releases/boost_1_36. For the next major release it would be
trunk and branches/boost_1_37.
If the release process can be made more automated (preferably nearly
fully automatic), all the features that people ask regarding the release
process will come nearly for free (without extra burden for either
developers or release managers).
That is you are able to keep a stable, *tested* interface on the release
branch (e.g. branches/boost_1_36), while providing hotfixes there (see
my other post), and you can easily create point releases by at some
point in time ensuring that test results are acceptable on the release
branch, tagging it, and creating a release package.
At the same time normal development and adding new features or interface
breaking changes is going on in trunk, which is also tested all the
time. For the next major release, you would just create a new branch,
branches/boost_1_37, from trunk, and switch testing to that new release
Also note that users wishing to keep up to date with all bugfixes, but
still wanting a stable interface, would just have to checkout and update
the current release branch, e.g. branches/boost_1_36.