[ANN] Squeak 3.5 released

Bert Freudenberg bert at isg.cs.uni-magdeburg.de
Sun Apr 13 10:20:05 UTC 2003

"Look Ma, I got the new Squeak 3.5!" -- "What's in it?" -- "...?"

Am Sonntag, 13.04.03 um 07:41 Uhr schrieb Doug Way:
> On Saturday, April 12, 2003, at 08:04 PM, Andreas Raab wrote:
>> Hi Daniel,
>>> Why not?
>> Because "version hopping" is a pain. Because the fixes could have 
>> trivially
>> posted for 3.4. Because if those fixes are important enough to 
>> signifiy a
>> release they *should* actually be available for people in 3.4. Because
>> people get confused about not seeing SM projects that have been 
>> marked as
>> 3.4 and are no longer visible in 3.5. Because there is simply not 
>> enough
>> "added value" for people to upgrade to 3.5.
> Some good points here.

Excellent points, exactly describing my thoughts. I've been quiet about 
this because, after all, I'm not actually doing the work. But this is a 
non-sense release, like all the other odd-numbered releases. At least 
you got this right ;-)

>> Funny you mention this and only as in "waiting for 3.6" - I have the
>> impression there's some deep down fear about posting any updates for 
>> already
>> released versions. Why is this so problematic for you guys? The 
>> updates are
>> there to be used or else you don't need an update mechanism to begin 
>> with.
>> What's the point of having the 3.4final stream if nothing is ever 
>> going to
>> be done here? What's the point in a 3.5final stream if nothing is 
>> ever going
>> to be posted here either?
> Appending late bug fixes to a final stream would probably be a simpler 
> way to handle this, true.

Indeed. A release with two fixes that need to be applied to 3.4 anyway? 

> Basically my only problem with this is that any stable version number 
> should refer to only one thing, IMHO.  So, if the "3.4" release refers 
> to the image with updates to 5170, then the image released with the 
> extra fixes beyond that (to update 5173) should have a different name 
> of some sort.  It could be "3.4.1", or "3.4 patch 1", or "3.5".  But 
> we shouldn't keep the name as "3.4"... if someone says they're using a 
> "3.4" release it should mean one and only one thing.  This is how 
> software/OS/programming-language releases generally work.

Not quite. This is the whole point of having a hierarchical version 
number system. 3.4 means *any* version of 3.4. When someone says he's 
running a Linux 2.2 kernel I know what to expect. Only when specific 
bugs are addressed I have to inquire about the point version - "yeah, 
that was fixed in 2.2.16".

> But I tend to agree that it would be best to use the existing final 
> stream for important post-release bugfixes.  If we did add a few 
> post-release fixes, and then waited for a time and no further fixes 
> were necessary, we could then issue an advance update to "3.4.1" or 
> "3.4 patch 1" or similar.
>  We would not want it to be "3.5" if we did this, since a full minor 
> update implies going through an alpha-beta-gamma cycle.  A name like 
> "3.4-5173" is not acceptable either, IMHO, for a stable release 
> intended for a wide audience.

If you want to avoid referring to changeset numbers (which IMHO is not 
a worthy goal) then you should bump up the tertiary version number 
*each time* you put a bunch of updates in the stream. But please *use* 
the update stream! It's one of the nicer features Squeak has had for a 
long time. It's even quite common in software nowadays, so why should 
we abandon it?

>> And, if you're not planning to make any use of it,
>> what's the point in flagging systems as "x.y final" at all? All you're
>> achieving by this is making it so that people need to do surgery on 
>> their
>> system if they ever want to update to the next one. In this situation,
>> wouldn't it be better if there were a straight-forward migration path 
>> which
>> effectively goes x.yfinal -> x.y+1 alpha?! If you're not using the 
>> final
>> stream there's no point in forking the update streams.
> Well actually, the split to the x.y+1 alpha stream often happens back 
> when x.y goes to beta or gamma, so the split can still be useful if we 
> want to add different things to x.ybeta and x.y+1alpha at the same 
> time.  And there is some value in simply marking a version as x.y 
> final even if the final stream is never used.  But I agree that it 
> might be useful to use the final stream in the manner I described 
> above.
> Anyway, the 3.5 release plan was a compromise of sorts, which we 
> arrived at relatively quickly.  Having thought about it more since 
> then, if a similar situation came up in the future, I would probably 
> vote to do something more like what I described above.  Live and 
> learn. ;-)

One point about release frequency (someone mentioned a 4-month cycle, 3 
releases each year):

The real problem with frequent releases is that each time we release 
something, we diminish the number of users / developers working in one 
release. That means older versions are never fixed, but just dumped. 
Doing a 2-year project? Yeah, sorry, that's too old, we don't support 
this anymore.

Enough ranting. Let's hope the next release will really have some 
value. I'd propose a december release date, so everyone has something 
nice to play over the holidays.

"Look Ma, I got the new Squeak 3.6!"

-- Bert

More information about the Squeak-dev mailing list