[Vm-dev] About VM version string

Tue Apr 12 15:58:37 UTC 2011

On Tue, Apr 12, 2011 at 2:20 PM, Igor Stasenko <siguctua at gmail.com> wrote:

>
> 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.
>
>
Yes, this make sense for me. I would put:  MetacelloConfiguration version +
git commit hash + the CMake Configuation class name used. Example:

CMakeVMMaker class: MTCocoaIOSCogJitDebugConfig.
ConfigurationOfCog version: '1.6'.
Gitorious CogVM blessed commit hash:
f3fe94c828f66cd0e7c37cfa3434e384ff65915e
Image where sources where generated: PharoCore.xxx

And I think that's is even more than what you need :)

Cheers

Mariano

> 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.
>

-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20110412/1b0e03e0/attachment.htm