In January, Karl sent
http://www.contactor.se/~dast/svn/archive-2004-01/0940.shtml, which
contained:
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