[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: RFC: Process for 1.x.0 releases

From: <kfogel_at_collab.net>
Date: 2004-07-19 16:07:35 CEST

Greg Hudson <ghudson@MIT.EDU> writes:
> I think it's appropriate to restart the soak period if we wind up
> making a big change (something on the scale of the mod_authz_svn
> change or larger). And if we're in the last week of the soak period,
> it makes sense to put off non-critical changes until 1.1.1. But it's
> silly to let our rules force us into putting out a 1.1.0 with known
> minor flaws which we found several weeks before we rolled the tarball.
> So, I'd suggest, for a .0 release:
> * Weeks 1-3: minor bugfixes can go in, following the same criteria
> as we'd use for a patch release (with the API rules relaxed
> because there's no release to maintain API compatibility with).
> We put out a second release candidate at the end of week 3 if we
> made any changes.
> * Week 4: only a critical bugfix can go in, and we put out another
> release candidate and restart week 4 if we do that. Other fixes
> are delayed until 1.x.1.
> * If a showstopper bug forces us to make a significant change, we
> restart the four-week soak period wherever we are. If we can't
> agree informally on whether a fix requires restarting the soak
> period, we vote.
> If this suggestion doesn't fly, then we're still at the status quo,
> which means changes merged into the 1.1 branch since 1.1.0-rc1 won't
> go into the 1.1.0 release. If this suggestion does fly, I don't see
> any reason why we can't apply it to the 1.1 release, since nothing
> changes until the end of week 3.

Sounds eminently sane.

Would you like to document this in HACKING? (If not, I'm happy to do
it, just say the word.)


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jul 19 17:37:56 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.