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 we
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 as
we come out with 1.x+1, we can do that while still creating a new branch
off the trunk for each 1.x release. (Unless the trunk has incompatible
svn 2.x changes on it. I would not expect to come out with a new 1.x+1
release once we start gearing up for svn 2.0, although we could
certainly do so by branching off an old rev of the trunk and merging in
the new features we want in it.)
> I wouldn't forsee us taking
> a FreeBSD-ish approach where every 4.x/5.x 'release' is a branch and having to
> release 'patch' releases to 1.0/1.1/1.2/1.3/1.4 when we're at 1.5 when we find
> a security vulnerability. Each 1.y+1 release should supercede the previous
> one from our perspective and close the previous 1.y release down.
So, in my world, in September 2004 we'll still have released only 1.0.x
stable releases, and we'll be gearing up for svn 1.1.
In your world, I guess we might have released (let's assume even/odd
here, since it's your world) svn 1.2.0, svn 1.4.0, and svn 1.6.0 by
then, and 1.6.x is the only release we'll make bugfixes to.
I guess we have different views of the conservatism and feature appetite
of the large part of our user base. I can easily see someone installing
svn 1.0 and running it for a couple of years. If a security hole is
discovered after eight months, it would be unfortunate if that person
has to upgrade to svn 1.6.1 to fix it, even if such an upgrade is
theoretically backward-compatible in all respects.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Dec 23 05:49:38 2003