[Vm-dev] About VM version string

[David T. Lewis]

Yes, I agree the detailed information needs to be something separate
from the version string. I think that Eliot added some useful hooks
to identify detailed version of sources with UUID strings (sorry I
am away and cannot check on where I saw this). Possible this will
be of some help.

I'd like to keep the VMMaker class>>versionString restricted to
answering strings of the form '1.2.3' or '1.2.3x' for consistency
with existing practice. Note that the implementation in oscog is
something left over from ancient history, so this should be changed,
maybe starting fresh with '5.1.1c' and start incrementing it to
'5.1.2c', '5.1.3c' ... where the 'c' implies cog?

I don't know how to come up with a short "platform version" number
for git similar to the Subversion revision number, but perhaps
just adopting manual process (i.e. edit a text file) would be
good enough for starters.

$0.02,

Dave

On Tue, Apr 12, 2011 at 02:20:15PM +0200, Igor Stasenko 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.
> 
> 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.