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.
Ick.
> 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.
Agreed.
> (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.)
If we decide to break compat and go for a 2.x release, then I would
suspect that we'd have two "live" branches: the new 2.x series, and
maintenance releases from a 1.x branch.
>
> > 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.
Agreed. I just don't like the branch strategy :-)
The versioning design means that it is *safe* to upgrade to the most
recent 1.x. If an admin installs something that requires >= 1.3, yet the
system only has 1.1 on it (along with a bunch of 1.1-based apps), then it
is totally cool for the admin to upgrade to an svn 1.4 installation. That
install will *not* break those 1.1 apps.
Because it is safe to upgrade, it means that we don't have to support old
1.x releases once 1.x+1 comes out. The answer will always be "upgrade".
And when the admin's eyes pop out, we explain how it is safe.
> 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.
I would hope for a 1.1 around June or July, but nits aside...
> 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.
That's the theory, though I'm with you (GregH) in that I don't think we'd
have that many releases.
> 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.
That is *exactly* the plan. 1.6.1 is a safe upgrade, so that is how the
administrator gets his bugfix.
I do tend to agree with you on the frequency of minor (1.x) releases,
however. And "a couple years" is probably the average. I could easily see
some people going with something for five years.
Now... all that said, if people really do have a problem with upgrading to
1.6.1 for their security fix, then we could bow to user demand and release
1.0.7 for them. Meanwhile, we're cranking on 1.7.x ...
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Dec 23 13:16:18 2003