[squeak-dev] Updating official 5.1 images

David T. Lewis lewis at mail.msen.com
Thu Dec 7 01:41:20 UTC 2017

On Wed, Dec 06, 2017 at 10:57:44PM +0100, Nicolas Cellier wrote:
> Hi,
> I opened https://github.com/hpi-swa/smalltalkCI/issues/350
> for fixing the tests of opensmalltalk-vm for squeak on linux 32bits.
> I uploaded the fix into source.squeak.org/squeak51 because I can...
> but now I wonder:
> - Is it a good policy?

Yes I think that this is good policy.

The 5.1 release image is a "known good" reference point. If you want
to build a VM with code generated from a known recent image, this would
be the expected reference point.

The squeak51 update stream is for important fixes, backported from trunk,
that should be applied to that reference image.

The fix that you uploaded to source.squeak.org/squeak51 is exactly that,
an important fix that should be applied to the 5.1 reference image. It
is very important in this case because other projects (the VM) need to
have this change, and should not have to wait around for us to release
another official "known good" reference image.

So I think that you did exactly the right thing.

> - Do we have some sort of patch number like in semantic versioning?
> https://semver.org/
> I know we have it in the image thru 'about squeak' menu and latest update
> number

I would think that this is sufficient from the point of view of identifying
the image that was used to generate the VM sources.

> The question is more about identifying that from the download site
> - Shall we then update the official 5.1 image?
> - Shall we keep a stack of successively patched images?
> - Who will do it?
> - Can the process be automated?

My opinion is that we should not try to keep a stack of successively patched
images. I think that it is better to have a smaller number of "known good"
release images, along with their dedicated update streams for important
patches, such as your example here. This is sufficient for most practical
purposes, and in the long run it is easier to understand for someone who
might want to refer back to an earlier version of Squeak.


More information about the Squeak-dev mailing list