[ANN] Squeak 3.5 released
Doug Way
dway at riskmetrics.com
Sun Apr 13 05:41:28 UTC 2003
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.
> 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.
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.
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.
> 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.
;-)
- Doug Way
More information about the Squeak-dev
mailing list
|