[Vm-dev] About VM version string

[David T. Lewis]

On Tue, Apr 12, 2011 at 12:53:20PM +0200, Igor Stasenko wrote:
>  
> Hello,
> 
> i'd like to know what we can do to clean up the mess with Cog VM
> versioning, so people could identify it more easily.
> 
> Currently , what
> 
> Smalltalk vmVersion shows is:
> 
> Smalltalk vmVersion
> 
>  'Croquet Closure Stack VM [StackInterpreter
> VMMaker-oscog-IgorStasenko.Stasenko.49] StackVM VM 4.0.0'
> 
> but it doesn't says anything about which version of platform sources
> are used to build it.
> Also, a version number VM 4.0.0 makes no sense..
> 
> I'd really like to see what we can do to improve it.

VMMaker class>>versionString is an ad-hoc identifier that I (and
hopefully others) update whenever making a functional update to
the VMMaker package. It is intended for two purposes:

1) Provide an approximate identification of the Smalltalk sources
(VMMaker plus plugins) used to create a VM.

2) Supply an identifier that becomes part of the VM name. On a
unix installation, this forms part of the name of the subdirectory
in which the VM in installed.

My recommendation:

In the oscog branch now, and ultimately in the merged code base
whenever we get there, adopt a similar #versionString convention
and get in the habit of updating it somewhat regularly. In the
near term, the names should not conflict with those used for the
VMMaker trunk (to avoid confusion especially in the installation
directory targets).

It may be helpful for clarity to add a one-character suffix to the
version string to identify a cog interpreter. Thus if the version
string for a standard interpreter is '1.2.3' then a cog VM could
identify itself as '1.2.3c' for example. Note that this is also
important for 64 bit versus 32 bit interpreter VMs (i.e. interpreter
for 64 bit object memory), so IMO it is a good thing to waste
some disk space on installation directories such that different
flavors of VM can clearly live in their own subdirectories.

The other half of the equation is the version number for the
platform sources. For the standard unix build, Ian has incorporated
the current Subversion number (derived at compile time) with
the VMMaker version string (generated at slang generation time)
into a version identifier for the VM, which in turn is used
to create the subdirectory name for the installation. Hopefully
there is some similar mechanism that could be done for the
git mirror and CMMakeVMMaker builds (although I do not know
enough to suggest how to do it).

The mechanism I am describing here is not very sophisticated,
but it's simple and has worked well in practice, so if there
is a way to do something similar with oscog VMMaker and the
git/CMake builds, I think that would be quite helpful.

Dave