[ANN] Squeak 3.5 released

Andreas Raab andreas.raab at gmx.de
Mon Apr 14 16:11:20 UTC 2003


Hi Göran,

> Personally I would like to drop the discussion on 3.5 - it's done.
> Perhaps it was a bad move to call it "3.5" instead of "3.4.1" but
> whatever, we learn.

Sure, no problem.

> Personally I don't think there is/should be any rule about not posting
> updates to a gamma release.

Maybe. And maybe not. It depends on the life cycle we're looking at. I could
imagine that there are rules against this if other benefits (such as easy
migration to the next version) outweigh it. I'm all in favour for everything
that makes migration to the "latest greatest" for Squeakers easier and
better understandable. If that means to have a few rules about dos and
don'ts that's fine.

> Last two rounds? 3.2 and 3.4? Am I missing something, wasn't 
> it used to get 3.2.1?

3.4 and 3.5 and their "aftermath" (not really but that's exactly what I'm
eluding to ;-)

> > Speaking for myself (as always ;-) it's the cycle of 
> > 3.4/3.5 and the general inclinations showing from the
> > guides that make me raise these points. I
> 
> Could you elaborate on the inclination bit?

Oh, I just have the impression that the Guides are a little more
cautios/conservative than SqC used to be and in this light the forked update
stream doesn't make as much sense at it used to do. In the SqC days we were
just always driving aggressively forward and for people who didn't want this
aggressive progress it made sense to navigate them into a "safe heaven" by
providing a separate update stream. But from seeing the length of
discussions, reviews, etc. that's going on right now it seems that the
advantages of the forked update stream simply don't apply anymore.

> I think the word "cautious" is better than "conservative". As 
> long as we don't have a solid testcode culture (but it is emerging)
> the only way to see if something is "bug free" is to simply wait and
> see if there are bugs reported. This means that in order to make a
> more solid release we simply must force ourselves to be "conservative"
> as you call it. That is at least my perception. 

Totally agree. I think it's an appropriate style of dealing with the
problems. Just that in this light some of the mechanisms we've used in the
past are not quite as appropriate here. For example, in the SqC days we've
hardly ever waited for "bugs to show" as you put it. If they show up (and
they sure do!) then you just fix them on the fly and post the result as an
update. The next (or even the same) day others will have this fix and "test
the fix". The point of the update stream is mostly a high turnaround rate -
you can rapidly post changes, fix problems, re-fix problems etc. But if
you're doing extended reviews before applying the changes then the mechanism
might simply no longer be the best to use. That's what I'm thinking.

> We shouldn't be as conservative when it comes to 3.6 IMHO. The whole
> *point* of being so conservative with 3.5 was to make sure it turned
> into a "better 3.4" instead of "another release with a few killer bugs
> in it" *so that* we can be less conservative with 3.6.

Well, actually I think that the conservative style is pretty appropriate. I
couldn't think of a better one unless you're doing this full-time. At the
very least it encourages some of the techniques that will make external
reviews easier (= writing code so that others can understand it) which - for
example - includes providing test cases where appropriate.

> > Hey, but _I_ am! Didn't you read my last message?! ;-)
> 
> Yes, I can read that but you sure are implying *we* are saying we
> shouldn't use the update stream. And we *sure aren't*. So why are you
> implying that? ;-) :-) (<= abundant smileys not to prolong a silly
> discussion)

Err ... because I think you should^H^H^H^H^H^H could?! ;-)

Cheers,
  - Andreas



More information about the Squeak-dev mailing list