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
Received on Sun Dec 21 18:40:24 2003