You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Greg Hudson <gh...@MIT.EDU> on 2004/07/16 18:02:44 UTC
RFC: Process for 1.x.0 releases
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
Re: RFC: Process for 1.x.0 releases
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Thursday, July 22, 2004 4:40 PM -0400 Greg Hudson <gh...@MIT.EDU>
wrote:
> Well, we can talk about more stringent release procedures for 2.0 when
> it comes time to go in that direction, but I can't think of many
> realistic scenarios where a four-week no-touching rule would really help
> prevent that kind of mistake.
It'd allow third-party apps a chance to test/migrate their apps during that
soak period without chasing a moving target. *shrug* -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: Process for 1.x.0 releases
Posted by Greg Hudson <gh...@MIT.EDU>.
On Thu, 2004-07-22 at 05:58, Justin Erenkrantz wrote:
> I think your proposed change makes sense for the A.B.0 case (B != 0), but what
> about the A.0.0 case? (i.e. 2.0.0.)
>
> Could we make the case that a four-week 'no-touching rule' might make more
> sense before the first release of a new major version? I'd think it might -
> because if we really screw something up, we might be at (A+1).0.0. -- justin
Well, we can talk about more stringent release procedures for 2.0 when
it comes time to go in that direction, but I can't think of many
realistic scenarios where a four-week no-touching rule would really help
prevent that kind of mistake.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: Process for 1.x.0 releases
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Friday, July 16, 2004 2:02 PM -0400 Greg Hudson <gh...@MIT.EDU> wrote:
> 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.
I think your proposed change makes sense for the A.B.0 case (B != 0), but what
about the A.0.0 case? (i.e. 2.0.0.)
Could we make the case that a four-week 'no-touching rule' might make more
sense before the first release of a new major version? I'd think it might -
because if we really screw something up, we might be at (A+1).0.0. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: Process for 1.x.0 releases
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Mon, 19 Jul 2004, Ben Reser wrote:
> On Fri, Jul 16, 2004 at 02:02:44PM -0400, Greg Hudson wrote:
> > 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.
>
> +1 from me.
And me.
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: Process for 1.x.0 releases
Posted by Ben Reser <be...@reser.org>.
On Fri, Jul 16, 2004 at 02:02:44PM -0400, Greg Hudson wrote:
> 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.
+1 from me.
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: Process for 1.x.0 releases
Posted by Max Bowsher <ma...@ukf.net>.
Ben Collins-Sussman wrote:
> On Fri, 2004-07-16 at 13:02, Greg Hudson wrote:
>
>> 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.
>
> I am *so* +1 on this. If we come to a consensus, I nominate ghudson to
> document this in HACKING. :-)
+1.
Makes a lot of sense.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: Process for 1.x.0 releases
Posted by Greg Hudson <gh...@MIT.EDU>.
On Sun, 2004-07-18 at 22:38, Ben Collins-Sussman wrote:
> I am *so* +1 on this. If we come to a consensus, I nominate ghudson to
> document this in HACKING. :-)
Done.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: Process for 1.x.0 releases
Posted by Ben Collins-Sussman <su...@collab.net>.
On Fri, 2004-07-16 at 13:02, Greg Hudson wrote:
> 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.
I am *so* +1 on this. If we come to a consensus, I nominate ghudson to
document this in HACKING. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: Process for 1.x.0 releases
Posted by kf...@collab.net.
Greg Hudson <gh...@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