On Tue, Jan 27, 2009 at 16:41, Hyrum K. Wright
<hyrum_wright_at_mail.utexas.edu> wrote:
> Greg Stein wrote:
>>
>> On Tue, Jan 27, 2009 at 15:15, Hyrum K. Wright
>> <hyrum_wright_at_mail.utexas.edu> wrote:
>>>
>>> ...
>>> We always roll at least 2 release candidates, one at the beginning of the
>>
>> Then that first "candidate" is NOT a candidate.
>>
>> Get real here. A "release candidate" means "we think this is ready to
>> go." You can't just go and make up new meanings. Call it a prelease
>> build or something. But it is NOT an RC if you are baking a second one
>> into the schedule.
>
> Sure the first one is a candidate: if there aren't any changes made during
> the soak, then we create the final from that one. If there are changes
> (such as translation updates, minor bugfixes, etc.) we roll the extra RC.
> That's been the policy from time immemorial.
If it is a release candidate, then only critical fixes should be
allowed and would let us back away from shipping it.
> From HACKING:
> "At the beginning of the final week of the stabilization period, a new
> release candidate tarball should be made if there are any changes pending
> since the last one. The final week of the stabilization period is reserved
> for critical bugfixes; fixes for minor bugs should be deferred to the A.B.1
> release. A critical bug is a non-edge-case crash, a data corruption problem,
> a major security hole, or something equally serious."
"... should be made *IF* ..." -- you don't *have* to create a new candidate.
And it really should say "if there any [critical] changes".
> I do *not* want to get into the scenario we got into with 1.5: "whoops,
> found another bug, time to roll rc28". The current "pre-soak" state on
> trunk is hopefully helping that not to happen.
Agreed. I'm saying that we should be able to ship the *first* release
candidate. That is what "release candidate" means.
If you are *planning* to do a followup build, then call the first one
a pre-release. IMO, we don't want to do that. "oh? this isn't final.
I'll wait for the final." I think we want to build a release
candidate, and if it looks good, then to ship the sucker.
Translation changes and minor fixes can go into the 1.6.1 release. We
don't have to hold the train for them. Patch releases can be cheap.
Why not ship a new patch release two weeks after 1.6.0? No biggy.
Cheers,
-g
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1059433
Received on 2009-01-27 17:36:25 CET