On Sunday, April 13, 2003, at 06:20 AM, Bert Freudenberg wrote:

> Am Sonntag, 13.04.03 um 07:41 Uhr schrieb Doug Way:
>
>> 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".

Right.  That's why I like a version number like "3.4.1" for this, 
because it implies that it is a 3.4-compatible release.  The idea being 
that it has only important bugfixes, so that 99+% of 
packages/changesets which work with 3.4 will also work with 3.4.1. 
(assuming further bugs weren't introduced in 3.4.1, which would 
necessitate a 3.4.2 release, etc.)  Whereas typically only 80-90% (just 
a guess) of packages will survive a full minor release update, such as 
moving from 3.5 to 3.6.

For example, if we used this convention, packages on SqueakMap could 
just list themselves as being compatible with 3.4, and the Package 
Loader would still show them as visible in a 3.4.1 image.  We probably 
wouldn't want a 3.4.1 category in SM.  (Yes, the visibility options in 
the Package Loader could probably be improved anyway, and with package 
dependencies the image-version category stuff will eventually be less 
important, but it's just an example.)

>> 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.

Yes.

> 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?

Don't worry, nobody's abandoning it just yet. ;-)

> 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.

Right, but it's a matter of finding the right balance.  A while ago, a 
few people suggested trying 1-month releases.  (I think those 
suggestions may have been a prod to see how fast is "too fast", rather 
than serious suggestions.)  But yeah, 1-month releases would cause big 
problems with a diminished number of users/developers working in each 
release.

But then we don't want to be so slow that it takes a year for a bug fix 
to finally show up in a final release.

If 4 months ends up feeling too fast, we could move to 6 months or 
similar.

- Doug Way