[Squeakfoundation]3.5 release timing (was Re: Outstanding 3.4 bugs?)
dway at riskmetrics.com
Tue Mar 4 01:45:28 CET 2003
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
(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,
> 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.
> 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
>>> It'll take more than two weeks before any decent number of people
>>> even downloaded 3.4, let alone done anything much to find and fix any
>> 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
>> all soon adjust. Eg when the world knows that "3.x comes out on the
>> it will get downloaded a lot quicker. If bugs or major enhancements
>> ready in time for the release, fine, they show up next month (or the
>> 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
>> 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
> Squeakfoundation mailing list
> Squeakfoundation at lists.squeakfoundation.org
More information about the Squeakfoundation