--On Sunday, December 21, 2003 12:24 PM -0500 Greg Hudson <ghudson@MIT.EDU>
wrote:
> * We should evaluate how often we see evidence that anyone is using
> them; if we don't, we should consider giving up on them, in which case
> we would only make stable releases (and testing releases during the
I don't see how you can evaluate whether people are using it or not. You
release it and move on. Why would it be harmful?
> stabilization period for a new release). People can still get svn from
> the trunk. (Though, if we see evidence of any Windows users using the
> snapshots, we should weigh that high, since many of them probably aren't
> able to build svn from source and thus can't get svn from the trunk.)
I think that'd be the biggest reason to have 'trunk' snapshots: binaries. A
lot of people dislike building from source even if they have a compiler, too.
That's been our biggest complaint within the ASF - people are finding buggy
binary packages and they don't want to build from source - it'd actually be
easier for them to build from source than use some of the broken binary
packages out there, but we haven't been able to make the case they should
build from source instead.
> I would actually hope that our schedule for new middle-number stable
> releases isn't too aggressive. We don't want a lot of different stable
> branches out there (it's hard to support), but neither do we want to
> force our users into making potentially traumatic upgrades every few
> months. So, I would say once a year or so is good for middle-number
> releases. I would also expect it to take us close to a year to
> implement any interesting new functionality.
I think the branch should really be 1.x, not 1.0. 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.
I also disagree that it'd take us close to a year to implement anything
interesting (both of us may very well be wrong: it's only speculation at this
point).
However, I think once we hit 1.0 and we get some large-scale users and more
people feel comfortable adopting Subversion, we're going to be implementing
some new functionality to fill the holes present in 1.0. If it's added after
1.0 and into the trunk and it shouldn't break anything, why shouldn't it be
released?
I'd hate for a year to pass with fixes/enhancements in trunk that were added
(say) a month after 1.0 comes out that are not released because we wish to be
overly conservative with conducting releases. 3-6 months, sure. But, 1 year?
I don't think we should be *that* conservative with minor releases. Major
version bumps? Definitely: only one per year, if that. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Dec 23 04:49:22 2003