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
|