You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Erik Huelsmann <e....@gmx.net> on 2003/12/21 11:20:43 UTC
Expected post-1.0 release cycle?
Related to the question about what Subversion version numbers mean is what
we expect to have for a release cycle after 1.0.0. Expectations about this are
going to influence what the version number means too.
In a recent mail Greg Stein expects the release cycle to continue as it does
now; i.e. a bi-weekly release. I expect he's talking about dev builds.
Karl Fogel has expressed the expectation that there will a half year silence
after 1.0 for public (i.e. stable) releases.
I guess that to be able to address the version numbering problem, we have to
have an idea about how we are going to proceed after 1.0.0 both for dev
builds and for stable releases.
Looking at the bi-weekly dev build release cycle I think this has worked out
really great. There has been some discussion whether this should continue
after 1.0. Given our current experience we should - IMHO - at least see if it
still works after 1.0.
Seeing that frequent releases have created a level of trust of active
development and support to a wide community already, I would like to suggest we
don't hold up patch level releases too long. If there's nothing to release, then
we shouldn't, but if there is, my preference would be to release per quarter
or 4 months. Shorter intervals might interfere with active development on
other releases, although obviously attention is going to have to be devided
between public and development releases anyway.
Hoping to contribute with this mail,
Erik.
--
+++ GMX - die erste Adresse für Mail, Message, More +++
Neu: Preissenkung für MMS und FreeMMS! http://www.gmx.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Expected post-1.0 release cycle?
Posted by Erik Huelsmann <e....@gmx.net>.
[ part about trunk releases snipped ]
> > Seeing that frequent releases have created a level of trust of active
> > development and support to a wide community already, I would like to
> suggest we
> > don't hold up patch level releases too long. If there's nothing to
> release, then
> > we shouldn't, but if there is, my preference would be to release per
> quarter
> > or 4 months.
>
> This comment doesn't make sense to me. "Patch releases" to me means
> things like Subversion 1.0.1, which we would release whenever we have a
> sufficient mass of important bugs to fix in Subversion 1.0.0. You don't
> typically do those things on a schedule. But "release per quarter or 4
> months" sounds like a schedule for new stable middle-number releases
> (the next one being either 1.1.0 or 1.2.0, depending on whether we go
> with even-odd).
Ok, then I might have taken Karl's comment about not releasing anything for
about half a year after 1.0 too litteral. From that I thought he was
collecting all bugfixes into carefully timed bugfix releases for which the first
release - if any - whould be approximately 6 months after 1.0. That seemed a bit
too long to me. On the other hand, I would understand that no 1.0.1 release
be made within a month after 1.0 to be able to collect enough bugfixes.
> 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 didn't mean to have to implement a great new feature every 2 months :-)
bye,
Erik.
--
+++ GMX - die erste Adresse für Mail, Message, More +++
Neu: Preissenkung für MMS und FreeMMS! http://www.gmx.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Expected post-1.0 release cycle?
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On Dec 23, 2003, at 8:49 PM, Justin Erenkrantz wrote:
> --On Tuesday, December 23, 2003 8:40 PM -0500 Garrett Rooney
> <ro...@electricjellyfish.net> wrote:
>
>> 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, they don't.
>
> If we are talking about major versions (1.x/2.x/3.x), yes: I'm in
> agreement. If we are talking about minor versions (1.1/1.2/1.3), well,
> no. ;-) -- justin
Well, I doubt that the difference between minor versions would be
enough to motivate someone to do the work in most cases, but if there's
some catastrophically bad data corrupting bug found after 1.1 is
released, and someone wants to port it back and release 1.0.whatever
with it, I don't see why that's a bad thing.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Expected post-1.0 release cycle?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Tuesday, December 23, 2003 8:40 PM -0500 Garrett Rooney
<ro...@electricjellyfish.net> wrote:
> 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, they don't.
If we are talking about major versions (1.x/2.x/3.x), yes: I'm in agreement.
If we are talking about minor versions (1.1/1.2/1.3), well, no. ;-) -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Expected post-1.0 release cycle?
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On Dec 23, 2003, at 8:31 PM, Justin Erenkrantz wrote:
> --On Tuesday, December 23, 2003 4:11 AM -0800 Greg Stein
> <gs...@lyra.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.
>>
>> 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.
>
> 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,
they don't.
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
of support.
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.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Expected post-1.0 release cycle?
Posted by Greg Hudson <gh...@MIT.EDU>.
On Tue, 2003-12-23 at 20:31, Justin Erenkrantz wrote:
> 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.
That should be easy to discourage: we'd have no way of numbering such a
release. :)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Expected post-1.0 release cycle?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Tuesday, December 23, 2003 4:11 AM -0800 Greg Stein <gs...@lyra.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.
>
> 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.
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.
I only want one open 1.x branch at a time. I'd do that with one directory,
but it could be cleaner multiple copies (hey copies are cheap). *shrug* --
justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Expected post-1.0 release cycle?
Posted by Greg Stein <gs...@lyra.org>.
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
Re: Expected post-1.0 release cycle?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Tuesday, December 23, 2003 8:27 PM -0500 Greg Hudson <gh...@MIT.EDU>
wrote:
> I'm still thinking once a year for new minor releases is about right,
> but maybe more "in the steady state" than "right away". So we'd have
> 1.1 closer to next July than next December, but 1.5 and 1.6 would be
> spaced more like a year apart, assuming we've had no cause to jump to
> 2.0 by then.
Yes, as I think the 1.x tree stabilizes, we'll be able to space it out more.
Initially, at the outset, I'd expect we might have to do one or two patch
releases to 1.0 immediately to fix some 'brown-paper bag' bugs. Then, we'd go
3-6 months taking feedback and making what changes we can and then produce a
new minor rev that addresses the 'biggest' concerns about 1.0 as 1.1. Then,
we'll have to see how it plays out from there. My crystal ball doesn't go out
that far. ;-) -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Expected post-1.0 release cycle?
Posted by Greg Hudson <gh...@MIT.EDU>.
On Tue, 2003-12-23 at 20:20, Justin Erenkrantz wrote:
> > 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.
> No, that's not what I said. I said 3-6 months for a minor release would be
> reasonable.
Huh. Sorry about that; I guess I misread. (And, we just crossed wires,
so take my most recent message to John Peacock as being based on the
same misconception.)
I'm still thinking once a year for new minor releases is about right,
but maybe more "in the steady state" than "right away". So we'd have
1.1 closer to next July than next December, but 1.5 and 1.6 would be
spaced more like a year apart, assuming we've had no cause to jump to
2.0 by then.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Expected post-1.0 release cycle?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Monday, December 22, 2003 11:49 PM -0500 Greg Hudson <gh...@MIT.EDU>
wrote:
> 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.
No, that's not what I said. I said 3-6 months for a minor release would be
reasonable.
Again, I don't think we're that far off, but there's a lot of confusion in
this thread. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Expected post-1.0 release cycle?
Posted by Greg Hudson <gh...@MIT.EDU>.
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
Re: Expected post-1.0 release cycle?
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Dec 22, 2003 at 07:48:48PM -0800, Justin Erenkrantz wrote:
> --On Sunday, December 21, 2003 12:24 PM -0500 Greg Hudson <gh...@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?
Confusion. Somebody might download a developer snapshot, yet thinking or
hoping for a stable release. It is relatively easy to lose the labelling
of "developer only" between us and that nifty little software repository
managed by some user group off in Kansas.
[ hmm. will we have Subversion User Groups? SUGs? :-) ]
>...
> 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.
This is only true for stable releases. I think it would be rare for
somebody to seriously demand a developer-release binary. When people are
looking for prebuilts, they are usually looking for stable builds.
>...
> Each 1.y+1 release should supercede the previous
> one from our perspective and close the previous 1.y release down.
Per my other email: yah.
>...
> I don't think we should be *that* conservative with minor releases. Major
> version bumps? Definitely: only one per year, if that. -- justin
Major version bumps imply an API or protocol or data change. My hope is
that we will *never* see that. But that is totally unrealistic since we
haven't seen a ton of widespread usage yet. Thus, my "realistic" desire is
that we hold onto the 1.x release for about two years, then we bump to
2.x, and we never bump the major version again. I would hope that we learn
enough within two years of feedback to build SVN such that we can lock
things down around a 2.x API. But even that won't hold, so any sort of 3.x
would be (say) 5+ years after that, when we move into larger functionality
domains and discover new needs which impact our APIs.
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
Re: Expected post-1.0 release cycle?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Sunday, December 21, 2003 12:24 PM -0500 Greg Hudson <gh...@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
Re: Expected post-1.0 release cycle?
Posted by Greg Hudson <gh...@MIT.EDU>.
On Sun, 2003-12-21 at 06:20, Erik Huelsmann wrote:
> Looking at the bi-weekly dev build release cycle I think this has worked out
> really great. There has been some discussion whether this should continue
> after 1.0. Given our current experience we should - IMHO - at least see if it
> still works after 1.0.
At the same time, based on what I see on IRC, I think a lot of our users
would like to get off the upgrade treadmill and just get work done. So,
I think we should expect:
* Fewer people will be interested in using these trunk releases.
* The people who do use them will be more adventurous and tolerant.
As a result, I think we don't need to commit as many resources to making
sure that post-1.0 snapshot releases are stable, compatible, or
polished. Specifically:
* The CHANGES file is still good.
* There's no need for soak time.
* There's no need to ensure that a snapshot is compatible with the
prior snapshot if we need to make protocol changes. (Though we're
probably doing something wrong if we're not maintaining compatibility
with the previous stable release.)
* 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
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.)
> Seeing that frequent releases have created a level of trust of active
> development and support to a wide community already, I would like to suggest we
> don't hold up patch level releases too long. If there's nothing to release, then
> we shouldn't, but if there is, my preference would be to release per quarter
> or 4 months.
This comment doesn't make sense to me. "Patch releases" to me means
things like Subversion 1.0.1, which we would release whenever we have a
sufficient mass of important bugs to fix in Subversion 1.0.0. You don't
typically do those things on a schedule. But "release per quarter or 4
months" sounds like a schedule for new stable middle-number releases
(the next one being either 1.1.0 or 1.2.0, depending on whether we go
with even-odd).
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org