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: http://thread.gmane.org/gmane.comp.lib.boost.devel/178864/focus=178958 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 branch. 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. Best regards, Christian