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.)
-Karl
---------------------------------------------------------------------
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