<br><br><div class="gmail_quote">On Tue, Apr 12, 2011 at 2:20 PM, Igor Stasenko <span dir="ltr"><<a href="mailto:siguctua@gmail.com">siguctua@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Thanks for information, David.<br>
<br>
Indeed, the version numbers like 'x.y.z' are mainly for users,<br>
but not for developers.<br>
As a developer, you may want to uniquely identify the exact build<br>
environment, including<br>
platform sources, vmmaker (and dependencies) and configuration used to build it.<br>
<br>
What are primitives in VM , which could give a wide information about<br>
what VM is used.<br>
<br>
The problem here is that i could build different flavors of VM , based<br>
on configuration used<br>
<br>
for instance here, what i put into CMakeLists.txt file header:<br>
<br>
# This is automatically generated file using CogMacOSConfig on 12<br>
April 2011 1:30:26 pm<br>
<br>
So, for instance, if i build debug version of VM, how we can reflect<br>
that somewhere,<br>
so people could see what VM is running.<br>
<br>
This thing gets complicated.<br>
<br>
Git are not using numeric revision numbers , since it makes no sense<br>
in distributed development model.<br>
Git using hashes to identify commits.<br>
<br>
So, i wonder what would be good approach to organize this mess.<br>
What i thinking that might be, we should have two (or maybe 3)<br>
different version infos in VM.<br>
<br>
The most short one is 'versionString' , which are just x.y.z version<br>
number and VM name (and maybe build date).<br>
<br>
Another is 'versionInfo' which could contain a more detailed<br>
information about VM, like MC package versions etc etc.<br>
<br></blockquote><div><br>Yes, this make sense for me. I would put: MetacelloConfiguration version + git commit hash + the CMake Configuation class name used. Example:<br><br>CMakeVMMaker class: MTCocoaIOSCogJitDebugConfig.<br>
ConfigurationOfCog version: '1.6'.<br>Gitorious CogVM blessed commit hash: f3fe94c828f66cd0e7c37cfa3434e384ff65915e<br>Image where sources where generated: PharoCore.xxx<br><br>And I think that's is even more than what you need :)<br>
<br>Cheers<br><br>Mariano<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
I am not sure about it, that's why i asking.<br>
<div><div></div><div class="h5"><br>
<br>
On 12 April 2011 13:34, David T. Lewis <<a href="mailto:lewis@mail.msen.com">lewis@mail.msen.com</a>> wrote:<br>
><br>
> On Tue, Apr 12, 2011 at 12:53:20PM +0200, Igor Stasenko wrote:<br>
>><br>
>> Hello,<br>
>><br>
>> i'd like to know what we can do to clean up the mess with Cog VM<br>
>> versioning, so people could identify it more easily.<br>
>><br>
>> Currently , what<br>
>><br>
>> Smalltalk vmVersion shows is:<br>
>><br>
>> Smalltalk vmVersion<br>
>><br>
>> 'Croquet Closure Stack VM [StackInterpreter<br>
>> VMMaker-oscog-IgorStasenko.Stasenko.49] StackVM VM 4.0.0'<br>
>><br>
>> but it doesn't says anything about which version of platform sources<br>
>> are used to build it.<br>
>> Also, a version number VM 4.0.0 makes no sense..<br>
>><br>
>> I'd really like to see what we can do to improve it.<br>
><br>
> VMMaker class>>versionString is an ad-hoc identifier that I (and<br>
> hopefully others) update whenever making a functional update to<br>
> the VMMaker package. It is intended for two purposes:<br>
><br>
> 1) Provide an approximate identification of the Smalltalk sources<br>
> (VMMaker plus plugins) used to create a VM.<br>
><br>
> 2) Supply an identifier that becomes part of the VM name. On a<br>
> unix installation, this forms part of the name of the subdirectory<br>
> in which the VM in installed.<br>
><br>
> My recommendation:<br>
><br>
> In the oscog branch now, and ultimately in the merged code base<br>
> whenever we get there, adopt a similar #versionString convention<br>
> and get in the habit of updating it somewhat regularly. In the<br>
> near term, the names should not conflict with those used for the<br>
> VMMaker trunk (to avoid confusion especially in the installation<br>
> directory targets).<br>
><br>
> It may be helpful for clarity to add a one-character suffix to the<br>
> version string to identify a cog interpreter. Thus if the version<br>
> string for a standard interpreter is '1.2.3' then a cog VM could<br>
> identify itself as '1.2.3c' for example. Note that this is also<br>
> important for 64 bit versus 32 bit interpreter VMs (i.e. interpreter<br>
> for 64 bit object memory), so IMO it is a good thing to waste<br>
> some disk space on installation directories such that different<br>
> flavors of VM can clearly live in their own subdirectories.<br>
><br>
> The other half of the equation is the version number for the<br>
> platform sources. For the standard unix build, Ian has incorporated<br>
> the current Subversion number (derived at compile time) with<br>
> the VMMaker version string (generated at slang generation time)<br>
> into a version identifier for the VM, which in turn is used<br>
> to create the subdirectory name for the installation. Hopefully<br>
> there is some similar mechanism that could be done for the<br>
> git mirror and CMMakeVMMaker builds (although I do not know<br>
> enough to suggest how to do it).<br>
><br>
> The mechanism I am describing here is not very sophisticated,<br>
> but it's simple and has worked well in practice, so if there<br>
> is a way to do something similar with oscog VMMaker and the<br>
> git/CMake builds, I think that would be quite helpful.<br>
><br>
> Dave<br>
><br>
><br>
<br>
<br>
<br>
</div></div><div><div></div><div class="h5">--<br>
Best regards,<br>
Igor Stasenko AKA sig.<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Mariano<br><a href="http://marianopeck.wordpress.com" target="_blank">http://marianopeck.wordpress.com</a><br><br>