On Fri, 2008-08-29 at 15:34 -0700, Eric Niebler wrote:
Understood. You want point releases. We don't have the resources right now. We are busy flushing the bugs out of a new release process that should give us quarterly releases. This is in response to feedback such as yours. Beman has said on this list that the issue of point releases will be reconsidered once we are meeting our quarterly release schedule. In the mean time, corporate users of Boost have a few options: (1) ignore hotfixes, (2) pay for support, (3) consider donating the testing resources we would need to produce point releases.
I thnk the new branching policy is fine as far as it goes, and I think the long lived (cross release) release branch makes perfect sense. The proposed patching process otoh makes no sense to me. The hotfix process as described seems to eschew use of subversion and the boost testing system in favour of a completely manual process of creating,releasing, testing and applying the patches. The patches if I understand correctly aren't even beased against the release to which they are supposed to apply. This seems to create work for everybody while reducing quality. What is wrong with an approach where a branch is made from the release branch at the time of release (or later, from the tag). I'll call this branch "maintenance" in the following examples. Note that this branch need not be made if teh release is "perfect". Also note that this is eassentially a whole of boost equivalent to a per-lib approach Robert Ramey suggested earlier: Boost developer wishes to make a change to fix a "production issue" - possibly by applying a user supplied patch against the release version. The change is made directly on the developers local copy of the maintenace branch, locally tested to the developers satisfaction then applied to the maintenance branch. It may or may not get tested there (see note 1). The developer also merges the change into trunk. A boost user wants to get all bug fixes applicable to the release they are using. The user pulls the head of the maintenance branch for that release. The user then runs the tests and generates library status locally. A user wants to find and apply the patch for a specific issue only. Use trac, find the change that addresed the issue, get the patch. This is involves no additional work for the developer to produce patch release docs etc and gives full traceability. Note 1: Ideally tests would be run automatically on the maintenance branch and the results published regularly. Users could simply look at the latest results and decide whether to use the maintenance branch head or not. However, as test result publication is currently a major resource bottleneck, this would depend on the donation of additional resources. For now, a maintenance branch that requires users to run their own tests, but makes doing so easy, seems to be a step forward from what is currently available.
In the future, I could imagine staggered releases ... something like a 3 month full release cycle, followed by 1 or 2 months to put out a point release. With extra resources, these two could happen in parallel, of course.
That could work - is it reasonable to close the release branch for changes from trunk for say 1 month after a release, and instead use it as a "maintenance" branch? This would avoid any extra testing load but (hopefully) allow the important x.y.1 point release to catch any "oops" problems to be tested and released. Arguably this is just extending something similar to the pre-release checkin policy after the release, which perhaps shouldn't be necessary. But the fact is that until boost.org has anointed code as "released" a lot of users won't touch it (with good reason). That could be changed with a high qaulity and well publicised beta, that is left in beta for "long enough" - but in relaity this is just a labeling issue for the releases more than a change to the procedure I've just suggested (1.36.0 would be 1.36 beta, 1.36.1 would be 1.36 release). Regards Darryl PS I do think the 1.36 release process was a big step forward and has worked really well. Thanks to all concerned.