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

[Doug Way]

Hmm.  Having gone through the process (well, at least most of it), I 
suppose a one-month release might be barely workable if the goal was 
limited to fixes only as you say.  One problem has been coordinating 
things via email (such as new VM releases, getting problems fixed), but 
I suppose these things get better when people know what to expect after 
the first time through.

The big question for me is whether we would want to have a fixes-only 
release.  In other words, how does the quality of the 3.4 release with 
respect to bugs compare with other recent releases?

I recall that the 3.0 release was pretty rushed, and there were some 
problems.  3.2 was somewhat better, it had a bit more time to settle.  
Even though 3.4 mostly just added support for SqueakMap and retrofitted 
some enhancements from 3.3alpha, there were a few dozen bug fixes made 
during the 3.4beta stage.  Which doesn't necessarily mean that much, 
but I think 3.4 did get more time for fixes and settling down than 3.0 
did, and probably has fewer largish bugs.  How it compares to 3.2... 
maybe about the same, maybe not quite as good, I'm not sure.

If we think that 3.4 is roughly on par with other Squeak releases 
quality-wise, I would tend to just have 3.5 allow enough time for 
package removals, enhancements, etc., in a more typical release 
timeline.  Whether that's 3, 4 or 6 months, I'm not sure.  Some Squeak 
releases have had 12 months between them, I'm sure we don't want it to 
be that long. :-)

But if we think we really need a higher-quality release before the 
image breakup begins, then perhaps a shorter fixes-only release is 
worth considering.

(I guess I'm leaning toward not bothering with the fixes-only release, 
but I'm still on the fence.)

- Doug Way


On Sunday, March 2, 2003, at 06:27 PM, Daniel Vainsencher wrote:

> Simon, the reason I very much am waiting to hear Doug on this topic, 
> and
> speaking about 1 month releases should be very tentative, is that none
> of us has Actually Done It. Doug might know how much the price of a
> release is, and how much it might be reduced, and whether he has time
> for it/someone else can do it in reasonable time, and those'll be the
> prime considerations in deterimining how often it will happen.
>
> Even doing only a short first release (without setting a fixed rythm
> yet), as I propose, depends on these parameters.
>
> Daniel
>
> Simon Michael <simon at joyful.com> wrote:
>> Tim Rowledge <tim at sumeru.stanford.edu> writes:
>>> I find it just about impossible to imagine getting stuff done that
>>> quickly given the geographic and chronologic spread of people 
>>> involved.
>>> It'll take more than two weeks before any decent number of people 
>>> heve
>>> even downloaded 3.4, let alone done anything much to find and fix any
>>> bugs.
>>
>> I think it's hard to imagine because we're all used to a different
>> process. However, with a steady monthly rhythm and known dates we 
>> would
>> all soon adjust.  Eg when the world knows that "3.x comes out on the 
>> 1st"
>> it will get downloaded a lot quicker. If bugs or major enhancements 
>> aren't
>> ready in time for the release, fine, they show up next month (or the 
>> month
>> after or..).
>>
>> NB in the worst case, release time rolls around and noone's had time 
>> to do
>> anything this month, we'd be just re-releasing (we'd probably skip 
>> that
>> one). That's fine. The larger process is far more important.
>>
>> Of course we can debate the optimal duration of an "iteration" - one
>> month, two months, three.. personally I feel one month works here. A
>> faster cycle allows us to learn and improve the process more quickly.
>> _______________________________________________
>> Squeakfoundation mailing list
>> Squeakfoundation at lists.squeakfoundation.org
>> http://lists.squeakfoundation.org/listinfo/squeakfoundation
> _______________________________________________
> Squeakfoundation mailing list
> Squeakfoundation at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/listinfo/squeakfoundation