[Squeakfoundation]3.5 release timing (was Re: Outstanding 3.4 bugs?)

[Ian Piumarta]

On Sun, 9 Mar 2003, Tim Rowledge wrote:

> Doug Way <dway at riskmetrics.com> wrote:
> 
> I'll just raise again my objections to the idea that it is possible to
> do any sensible beta in only a couple of weeks and any plausible gamma
> ditto.

I agree with Tim.  In fact I think I would generalise this to say thay
imposing a hard timeline on any [potentially unbounded] activity is a
risky business.  Why not plan the release cycle around the notion of
outstanding unfixed bugs, rather than on hard deadlines?  That way the
_state_ of the system drives the releases, rather than vice-versa.

Last wek somebody mentioned bug tracking system.  If we had one, with a
notion of "critical bugs", "invonveniences", and "cosmetic fixes" for
example, then something like this (starting from the last stable release)
might make sense:

PAR

  SEQ

   - decide what new stuff wants to be in (or taken *out* of the system
     and put into a SM package) in the next release

   - make a new image and tag it as "alpha"

   - invite all concerned to hack on the changes

   - when things have settled down, tag the image as beta and
     make it available for download for anyone who wants to
     help with beta testing

   - wait for the bug reports to come flooding in ;)

2: - fix bugs (of any and all priorities)

   - while (critical bugs != 0) sleep(several days); goto 2

   - tag the image as "gamma" or "release candidate" or
     whatever, and then announce it for public consumption
     on all the lists and invite each and every Squeaker
     to give it a go

   - sleep (a week or two)

3: - while (critical bugs remain): fix bugs; post updates;
     sleep(a few days); goto 3

   - tag the image as final and release it

  ENDSEQ

  SEQ

   - collect new feature requests for the next stable release

  ENDSEQ

ENDPAR

Ian