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

RFC: Process for 1.x.0 releases

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2004-07-16 20:02:44 CEST

In January, Karl sent
http://www.contactor.se/~dast/svn/archive-2004-01/0940.shtml, which

  If we do find a showstopper bug in 0.37.0, then we release 0.37.1 as
  per usual procedures, then run the above algorithm with "0.37.1"
  substituted for "0.37.0". In which case, the four-week countdown
  would start from 0.37.1's release date, not 0.37.0's, of course.

No one objected to that, and today in HACKING, we have:

  A major or minor release soak starts with A.B.0-rc1. There will
  only be an A.B.0-rc2 and higher if necessary, as each such release
  restarts the soak period. Once A.B.0 is out, subsequent releases in
  that line do not require a four week soak, because only conservative
  changes go into the line.

And I think the implication is that we won't make changes (apart from
doc changes, translation changes, and release housekeeping changes)
without putting out another release candidate either.

I don't think this makes sense. (And Ben agrees with me, via IRC.)
If four weeks is enough time to shake out the critical bugs in the
entire 1.1 development line, do we really need another four weeks to
shake out the critical bugs arising from the kind of commits we'd make
for a patch version?

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.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jul 16 20:11:19 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.