squeak vm version numbering

 

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 ?

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.




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

 

The 5.0 seems to be defined by VM_VERSION in
platforms/Cross/vm/sqVirtualMachine.h.

I've tested setting this to "5.3.1" and that seems to work, although that
the configure script --with-vmversion seems to express a preference for 2
digit version numbers (major and minor).

The --with-vmversion=5.3.1 of the configure script doesn't seem to do
anything while changing sqVirtualMachine.h does.



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

 
Hi Stes,

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

 

ok ... VM_VERSION remains 5.0 then ...

I think, after reading your reasoning, that I'm confusing squeak version
number and vm version.

Basically I'm not very familiar with Squeak and for me (from my point of
view) this is one "package", but it makes sense to distinguish vm and image.



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