[Squeakfoundation]re: release management (was"WeakMessageSends/Events for 3.4")

[Doug Way]

I basically agree with what Craig posted, especially the point about diluting the meaning of a final release.  The "Life cycle of a release" swiki page sounds like a good summary for now.

I had mostly [fix]es in mind when I brought up the list of ~30 submissions for us to review.  I thought that perhaps one or two very small [enh]ancements might be okay also, but in retrospect, sticking with the rule of "fixes only" for the beta stage is a good idea.  We are shooting for a final release quite soon (by the end of the year), so it won't be long before 3.5alpha is opened and we can incorporate plenty of enhancements at that time.

So, as much as I'd like to see the hierarchy & shrinking selection enhancements go in, they can wait until next month.

I'll post soon with a summary, taking everyone's feedback into account.

- Doug


Daniel Vainsencher wrote:
> 
> Yes, we're missing this information from the Swiki.
> 
> I added this and more in
> http://swiki.squeakfoundation.org/squeakfoundation/89, linked off of 79
> (release plan).
> 
> Feel free to add, correct, delete out right... ;-)
> 
> Daniel
> 
> Craig Latta <craig.latta@netjam.org> wrote:
> >
> > Hi Rob--
> >
> > > So when is 3.4 final scheduled for release? How about today?
> > > Just do it and if there are bugs, then patch it in the update stream.
> > > You are right that we can always play in 3.5.
> >
> >       I recommend against that approach. Remember that "final" releases are,
> > currently, what newcomers are most likely to use first. I think each
> > final release should be at least as stable as the previous one. We
> > should come as close as is practical to "all scheduled features
> > implemented, with no known bugs".
> >
> >       In the beta stage ("all scheduled features implemented, but there are
> > bugs"), we should only consider bugfixes. Given that we have a strong
> > interest in getting to a final release quickly, we should only consider
> > fixes to *critical* bugs (e.g., those which make the system unusable for
> > a newcomer). We shouldn't rely on patching the final release, because,
> > among other things, it annoys newcomers. It dilutes the meaning of
> > "final" and is bad PR. :)  I think patching a final release should be
> > extremely rare, done only to fix the most egregious problems (e.g., the
> > system won't start), and done completely seamlessly. Hopefully, the
> > gamma stage ("this will be the final release if no bugs are reported by
> > a deadline") catches anything that severe.
> >
> >
> > -C
> >
> > p.s. I am, of course, rehashing
> > http://netjam.org/smalltalk/versions.html. :)
> >
> > --
> > Craig Latta
> > improvisational musical informaticist
> > craig@netjam.org
> > www.netjam.org/resume
> > Smalltalkers do: [:it | All with: Class, (And love: it)]
> > _______________________________________________
> > Squeakfoundation mailing list
> > Squeakfoundation@lists.squeakfoundation.org
> > http://lists.squeakfoundation.org/listinfo/squeakfoundation
> _______________________________________________
> Squeakfoundation mailing list
> Squeakfoundation@lists.squeakfoundation.org
> http://lists.squeakfoundation.org/listinfo/squeakfoundation