On Dec 23, 2003, at 8:31 PM, Justin Erenkrantz wrote:
> --On Tuesday, December 23, 2003 4:11 AM -0800 Greg Stein
> <firstname.lastname@example.org> wrote:
>> On Mon, Dec 22, 2003 at 11:49:00PM -0500, Greg Hudson wrote:
>>> On Mon, 2003-12-22 at 22:48, Justin Erenkrantz wrote:
>>> > I think the branch should really be 1.x, not 1.0.
>>> What would we do, merge the entire trunk to the 1.x branch each time
>>> gear up for a new 1.x? Merge specific new features?
>>> Even if we make frequent new 1.x releases and desupport 1.x as soon
>>> we come out with 1.x+1, we can do that while still creating a new
>>> off the trunk for each 1.x release.
> My concern is that committers will want to add new functionality to a
> 1.x release when 1.x+1 release has already been released.
> If we decide to close the 1.x branch after 1.x+1 is out, then I think
> we're just talking really minor points - it's a matter of how best to
> use Subversion itself. FreeBSD's model is not to ever close down any
> branch; changes still go into every prior release. I think that'd be
> a giant nightmare.
Well, let's be fair, FreeBSD only gives official support for fairly
recent branches, as in they only port security fixes back to the last
few. Other than that, the older branches are as well supported as the
committers want to make them. If people are willing to do the work of
porting changes back to previous branches, they get backported, if not,
Now realistically speaking, unless there are some pretty radical
changes in new versions of Subversion, stuff that would keep people
from upgrading to it, there's little cause for us to provide that kind
But that said, if someone wants to do the work of porting critical
bugfixes (not large features, but bug fixes or VERY small features)
back to old branches and roll a release, I have no problem with that,
and I can't see why we would prohibit it. It's certainly better to let
them do so in public and have the change have some sort of review than
to have numerous people keeping local patchsets for their local version
if they don't want to upgrade for some reason.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Wed Dec 24 02:41:44 2003