On 15.03.2010, at 07:54, Edgar J. De Cleene wrote:
> 
> 
> On 3/14/10 11:35 PM, "Ken G. Brown" <kbrown at mac.com> wrote:
> 
>> You might want to reconsider freezing at update 9371.
>> This is already 310 updates behind the latest when I checked today.
>> That is: three hundred and ten updates behind. Not version 3.10.
>> 
>> Seems to me like a lot to be behind when doing a release.
>> 
>> Ken G. Brown
> Ok, we could go to the last update number the day 4.0 is on Squeak site and
> becomes the last version.
> 
> Edgar

That makes sense if we want to ship 4.1 as soon as possible after 4.0 is released. But this talk of "update numbers" does not make sense. While the freeze is in effect and bugs get fixed, the "update number" will change.

"Freeze" means "stop development of new features" and "only important bug fixes go in". Not "go back to some point in the past".

When the release manager announces a freeze, he lists which bugs need to be fixed before the release is done. Typically these are marked as blockers in the tracker. Only fixes for those bugs are allowed to be committed to trunk (though one might request exceptions). Once all blockers are fixed (or it's decided they are not blockers after all), *that* version is going to be released. The release manager takes it and packages it, but he does not add a single code change. That would be a release candidate. If changes are necessary, they are committed to the trunk and another release candidate is built. Only when the release went gold, the freeze is lifted, happy hacking can resume.

This process ensures that all those interested in the happy hacking will be interested in keeping the freeze as short as possible. So they should fix the blockers quickly so they can go back to the fun stuff :)

- Bert -