[ANN] Squeak 3.5 released
goran.hultgren at bluefish.se
goran.hultgren at bluefish.se
Sun Apr 13 20:01:28 UTC 2003
Bert Freudenberg <bert at isg.cs.uni-magdeburg.de> wrote:
> "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.
First of all - IIRC not many raised their voices agains the short "bug
fix" 3.5 release when it was being discussed. Doing it now feels a bit
Anyway, there were several reasons for doing this short release - since
the bugs in question were described as serious for some of the Squeak
users we wanted to get a better base release before jumping into the
"ripping the image apart" phase.
There has been an idea about introducing a more lax version filtering
mechanism in the package loader but it hasn't been implemented.
> 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
Ok, excuse me for asking - but why were you quiet? Perhaps it would have
been better if you spoke up earlier. IMHO. We are all in this together
and we are trying to do this "the right way" and please everybody, but
we need to hear what you all think.
I am going to post a draft on the 3.6 plan later tonight and it would be
nice to see these discussions *before* that release instead of after.
> 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?
Andreas - you must be aware of the discussions about the quick 3.5
> > 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?
Come on - this has been discussed on the list. I can't think you have
missed it too.
> > 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".
Sure. And we did that with 3.2.1. I think the point here was that we
actually wanted 3.4 to be the important robust release that people could
use "out of the box" for some time when we start turning things upside
Unfortunately 3.4 had some nasties in it and after long (in some ways
time wasting) discussions on the lists we came to the decision to do a
fast 3.5. Perhaps it was simply a mistake - obviously you are telling us
It would have been immensely more useful for us to hear this before the
> > 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?
Come on - who is saying we shouldn't use the update stream? Nobody
This is simply FUD. ;-)
> 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.
Well, the frequency is also a subject that has been discussed a lot. I
agree that too frequent releases can cause the scenario you are
describing. A lot of people have on the other hand asked for a higher
frequency and many an even higher frequency than 4 months.
I like the idea with trying to make the releases more frequent and I
don't think the problems will arrive in the form you describe - but in a
different form. 3.6 will include the 10 package removals currently on SM
and perhaps a few more. So Squeak is turning into a collection of
packages. The image is shrinking.
This means that the "official Squeak release" will in some ways be
harder to define and coordinate. Packages will be able to have their own
cycles and will need to be integration tested with each other etc. In
many ways Squeak official will resemble a Linux distribution - Debian
being perhaps the most clear example.
So... I think this potential problem can be handled using a proper
dependency scheme, but we will see.
More information about the Squeak-dev