[Vm-dev] squeak vm version numbering

Eliot Miranda eliot.miranda at gmail.com
Wed Apr 1 14:34:21 UTC 2020


Hi Stes,

> On Mar 31, 2020, at 3:53 AM, stes <stes at telenet.be> wrote:
> 
> 
> 
> There seems to have been in the past a "change" in version numbering. 
> That's quite common of course, version numbering schemes always change 
> 
> As far as I currently understand there is the 4.x series of Squeak images
> and vm's.
> 
> # squeak -version
> 4.16.7-3775 #1 XShm Tue Mar 31 10:36:25 CEST 2020 cc
> SunOS gecko 5.11 11.3 i86pc i386 i86pc
> plugin path: /usr/lib/squeak/4.16.7-3775 [default:
> /usr/lib/squeak/4.16.7-3775/]
> 
> Note that this is X.Y.Z version 3 numbers : 4.16.7
> 
> On the other hand with the "Spur" recent 64 bit images, this is now replaced
> by GIT commit
> 
> This is in the V5 Squeak with 5.x Squeak images in 64bit.
> 
> # squeak -version
> 5.0-202003291930-solaris  Mon Mar 30 17:47:52 CEST 2020 cc [Production Spur
> 64-bit VM]
> CoInterpreter VMMaker.oscog-eem.2731 uuid:
> 3c8dda9e-4706-4c3d-8c58-a284c47f5705  Mar 30 2020
> StackToRegisterMappingCogit VMMaker.oscog-eem.2731 uuid:
> 3c8dda9e-4706-4c3d-8c58-a284c47f5705 Mar 30 2020
> Date: Sun Mar 29 21:30:18 2020 CommitHash: 22060579c
> SunOS gecko 5.11 11.3 i86pc i386 i86pc
> plugin path: /usr/bin/../lib/squeak/5.0-202003291930-solaris [default:
> /usr/lib/squeak/5.0-202003291930-solaris/]
> 
> 
> Note that the plugin path and version here is X.Y 2 numbers 5.0.
> 
> This is understandable as GIT has more concepts like "CommitHash" and so on
> , rather than 'old style' version numbers.
> 
> However it could still be interesting I think to keep the tradition of the 3
> number version,
> this is with the updateSCCSversion script, I believe.
> 
> Is there a plan to keep the VM version number to keep matching the Squeak
> image versions ?

No, and they should /not/ track image versions.  The VM is always backwards-compatible; newer VMs can be used to run older images of the same architecture, so one can expect that any 5.x VM newer than a 5.x image can run that image.  Images are forwards compatible; they may use new VM functionality that is absent in older VMs, and so one cannot expect newer images to run on older VMs.

So we (strive to) guarantee that a new VM with a given major release number runs all existing images of that major release number.

With the up coming 6.0 release we may choose to bump the VM to 6.0 also, which may give us the freedom to sunset old code.  For example, VM event handling code is a convoluted mess and could do with being simplified.  But if we wanted to produce bug fix versions of 5.x VMs, then doing this would mean at least duplicating the platforms/XXX/vm directories to have, say, platforms/XXX/vm5 alongside to hold the older code. We may choose to live with the messy event code for a while longer, in which case 6.0 VMs will happily run 5.x images.

> 
> For the squeak image it is 6.0 alpha or 5.3 I see.  But they also have 5.3
> rc1 , rc2 etc.   That could correspond to 5.3.1 5.3.2 etc.

Which is not compelling, for reasons expressed above.

> --
> Sent from: http://forum.world.st/Squeak-VM-f104410.html


More information about the Vm-dev mailing list