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