2008/5/24 Peter Dimov <pdimov@pdimov.com>:
OK. To explain why the question is important, and why the proper time to ask it is now:
Developers need to know how to deal with bug reports against x.0. The usual procedure is to issue x.1 with the bugs fixed. For this to happen, the bug fixes need to be committed somewhere. Currently this somewhere is the release branch due to lack of alternatives.
If we're leaving the x.1 door open, we need to address this question, and we need to address it before parts of trunk get merged into the current release branch. One easy way is to copy release to release_1_35 so that the 1.35.0 bug fixes have a place to go. The obvious problem is that no tests would be running against that branch.
Indeed, this is the best solution as it provides a branch for maintenance of a given release. Although current practice is not to provide any kind of longer term support for a release, I can't see why, should a volunteer step forward to maintain a given release for longer periods why a branch shouldn't continue to exist for a given release, by not naming the branches with the release number I think you will be shooting yourself in the foot for the longer term. Sure you could create a branch from the tag but that just feels messy to me IMO (and again not ideal for importing into DCVS systems btw. if anyone wants a complete boost history in git I can make that available).
Another alternative is to release 1.35.1 first from the current release branch, then start 1.36. The obvious problem is the possibility of 1.35.2.
A third alternative is to declare that we're no longer going to issue point releases. This implies that the proper place to fix bugs against x.0 (before the x+1.0 merges happen) is on trunk.
I'd strongly argue against this alternative for two reasons: 1. A new version implicitly brings with it new libraries, potentially new APIs and deprecations. For a company relying on boost in their project an upgrade every 3 months that isn't just bug fixing can potentially become a major job and more critically one that doesn't get done due to time/budget constraints. 2. We're not always going to get a release right; should we mess up then why shouldn't a quick point release be viable; in fact why should point releases take much time at all? I'd suggest that after a release testing on a released branch should become on commits only and that commits should only be in response to trac tickets against the release, no other commits should be allowed. I think that this would ease the process of making point releases and wouldn't be a huge workload IMO, also I don't think we should be afraid of making quick point releases (Since this is essentially what happens once we get to beta/RC stage anyway), even if they only fix 1 or bugs, it all helps to increase the quality of boost that the end user sees. James