On Fri, 2009-07-17 at 19:01 +0200, Bert Freudenberg wrote:
> In any case a process where development slows down when nearing a  
> release would be in order, we might need feature freezes etc. Maybe we  
> simply set a release date now and then work towards it?
> 
> - Bert -

I would suggest an alternate model.  Rather than forcing developers as a
group to follow some sort of schedule why not consider a release a
snapshot of the development trunk minus some questionable or problematic
updates plus some additional cleanups relevant to a release.

Let's say I wanted to create a release today and let's posit that there
are a number of known good updates after Nebraska 14 and 15.  I could
update to the update just before Nebraska 14, then manually merge in the
updates afterward.  Then do whatever clean up I want to do.  Then
release.

Ken

P.S. One thing the new update stream does appear to lack compared to the
old update stream is the ability to easily update only up to a certain
update number.  Is there some way that could be implemented?  Clearly
the trunk is not the simplistic linear thing the old update stream was.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20090717/6a2ec02c/attachment.pgp