Shared variables binding/lookup bug

Doug Way dway at riskmetrics.com
Thu Oct 9 17:18:34 UTC 2003


Mark A. Schwenk wrote:

> So I take it we don't have a process for an update stream of critical 
> updates for the currently stable release as we did in days of yore?
>
> This was a routine process under Squeak Central. Fixes would be 
> applied to the current alpha stream and then back ported as updates to 
> the stable image if the updates in question seemed worthy of the effort.
>
> I'm not passing judgement on this particular update, but I think 
> having a process in place for critical updates to the current stable 
> image is A GOOD THING.


We still have the capability to do this.

The only slight change from previous practice is that I am somewhat 
opposed adding patch updates to a final release without (at least 
slightly) altering the version number for the release.  The idea being 
that "3.6" means one and only one thing.  So, for example, we can add 
one or two critical patches to the update stream for 3.6, and then if 
those patches seem to work and things settle down a bit, we put a 3.6.1 
release on squeak.org.  I think this would be okay as long as we're 
consistent that a secondary point release is always just criticial bug 
fixes: API's should not change, all apps written for 3.6 should work 
with 3.6.1, we probably shouldn't bother with a "3.6.1" version category 
in SqueakMap, we don't do any special PR for the 3.6.1 release, etc.

For the patches after 3.4 we decided to call the patched version "3.5", 
which was overkill in retrospect.

(An alternative is to use the terminology 3.6-5426 as the public name 
for a patched final release, but this is not easy to remember and is 
unacceptable IMHO.  The vast majority of software products avoid this 
practice, for good reason.)

But generally, we should avoid the patches/point releases if possible.  
But sometimes it is unavoidable. :-)

- Doug




More information about the Squeak-dev mailing list