2008/5/24 Jens Seidel <jensseidel@users.sf.net>:
On Sat, May 24, 2008 at 07:22:06AM -0400, Beman Dawes wrote:
Peter Dimov wrote:
If yes, we'll need two release branches, one for 1.36.0, one for 1.35.x.
Yes. branches/release will be for 1.36.0. I haven't given any thought to what the other should be named.
How about the usual name: branches/stable?
Again let me reiterate, I'd advise against trying to keep a constant branch name such as branches/release or branches/stable just because moving branches in the repository is a bad idea, just include the version number in the branch name! This kind of system works if you have a good merge tool, but quite frankly subversion is a rubbish tool for doing merges; distributed version control systems provide far better merge tools that enable this kind of integration to be done easily; again I refer people to the example of the linux kernel or git for how this kind of thing is done.
Either way: what would the procedure for the 1.36 branch be? What is its starting point,
branches/release
Maybe this could be renamed into branches/next_release.
Try to avoid moving branches as I suggested earlier it makes it harder to migrate to other version control systems in the future and also plays havoc with working copies if a new branch with the previous name is then created again as subversion doesn't detect the move. This is part of the reason I consider subversion's branching model of using paths for branches to be broken.
It is fine with me if someone else manages a 1.35.1 release, although it isn't clear to me who that someone would be. Dave Abrahams is interested, but I doubt he has the time available.
I'm personally concentrating on smoothing out the regular quarterly release process so that releases happen as scheduled and with more quality assurance than is currently the case. That leaves me no time to manage point releases.
Do you not consider point releases as part of the release schedule? I think given Boost's complexity that point releases should be a given and in fact that point releases will help increase quality assurance since they are fixing the very problems that slipped through the net for the current release. IMO the only way to get a smoother release process is to instigate hard feature freezes for releases. I can't help but feel from observing the release process that too many last minute features are allowed in; this is kind of a chicken and egg problem; these features are pushed to go into the release because of the long release times, but at the same time its these addition of features that slow the release down at the same time. James