Re: [boost] [filesystem][xpressive] Hotfix patches available for 1.36.0

From: Darryl Green (darryl.green_at_[hidden])
Date: 2008-08-30 22:55:27

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.