[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?
Ouch!
> 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
|