[Vm-dev] About VM version string

[Igor Stasenko]

Thanks for information, David.

Indeed, the version numbers like 'x.y.z' are mainly for users,
but not for developers.
As a developer, you may want to uniquely identify the exact build
environment, including
platform sources, vmmaker (and dependencies) and configuration used to build it.

What are primitives in VM , which could give a wide information about
what VM is used.

The problem here is that i could build different flavors of VM , based
on configuration used

for instance here, what i put into CMakeLists.txt file header:

# This is automatically generated file using CogMacOSConfig on 12
April 2011 1:30:26 pm

So, for instance, if i build debug version of VM, how we can reflect
that somewhere,
so people could see what VM is running.

This thing gets complicated.

Git are not using numeric revision numbers , since it makes no sense
in distributed development model.
Git using hashes to identify commits.

So, i wonder what would be good approach to organize this mess.
What i thinking that might be, we should have two (or maybe 3)
different version infos in VM.

The most short one is 'versionString' , which are just x.y.z version
number and VM name (and maybe build date).

Another is 'versionInfo' which could contain a more detailed
information about VM, like MC package versions etc etc.

I am not sure about it, that's why i asking.


On 12 April 2011 13:34, David T. Lewis <lewis at mail.msen.com> wrote:
>
> 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
>
>



-- 
Best regards,
Igor Stasenko AKA sig.