[prev in list] [next in list] [prev in thread] [next in thread] 

List:       squeakfoundation
Subject:    Re: [Squeakfoundation]re: release management
From:       Doug Way <dway () riskmetrics ! com>
Date:       2002-12-10 23:35:56
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]