On Fri, Mar 17, 2017 at 7:47 PM, Sven Van Caekenberghe wrote:
> I understand why it is useful to you, but it is a PIA for all the rest of
> us.
>
> Consider:
>
> $ java -version
> java version "1.8.0_60"
> Java(TM) SE Runtime Environment (build 1.8.0_60-b27)
> Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode)
>
> $ python --version
> Python 2.7.10
>
> $ ruby --version
> ruby 2.0.0p648 (2015-12-16 revision 53162) [universal.x86_64-darwin16]
>
> At the image level Pharo has:
>
> $ pharo Pharo.image printVersion
> [version] 4.0 #40620
>
> Clean, simple, precise.
>
> And then when the rest of the world wants to communicate about the VM
> version they are using, you get:
>
> $ ../bin/pharo --version
> 3.9-7 #1 Thu Apr 2 00:51:45 CEST 2015 gcc 4.6.3 [Production ITHB VM]
> NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.21 uuid:
> 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr 2 2015
> NBCogit NativeBoost-CogPlugin-EstebanLorenzano.21 uuid:
> 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr 2 2015
> https://github.com/pharo-project/pharo-vm.git Commit:
> 32d18ba0f2db9bee7f3bdbf16bdb24fe4801cfc5 Date: 2015-03-24 11:08:14 +0100
> By: Esteban Lorenzano Jenkins build #14904
> Linux pharo-linux 3.2.0-31-generic-pae #50-Ubuntu SMP Fri Sep 7 16:39:45
> UTC 2012 i686 i686 i386 GNU/Linux
> plugin path: /home/audio359/pharo/bin/pharo-vm/ [default:
> /home/audio359/pharo/bin/pharo-vm/]
>
> This is way too technical.
>
This just needs to be --versionVerbose or --versionAll.
cheers -ben
> On the other hand, I understand that this is also a vetting problem: who
> builds the VM, validates it, assigns it version/build numbers.
>
> BTW, is there no open source convention of using xx-config to return all
> this detailed (build) info ?
>
> > On 17 Mar 2017, at 11:36, Eliot Miranda wrote:
> >
> > Hi Ben,
> >
> >> On Mar 16, 2017, at 8:32 PM, Ben Coman wrote:
> >>
> >> A niggle I've had for a while is that the "Image Version" field seems
> to me to be useless.
> >>
> >> It defaults to a particular major version.
> >> (that even though only a small thing, is one more thing to maintain)
> >>
> >> It tends to be superseded by the Milestone field.
> >>
> >> The limited selection of major version is too broad to add any
> >> useful info beyond Milestone to narrow down action.
> >>
> >> So I wonder Image Version if it might be replaced by a freeform field
> >> "Image Version" to enter the value from System > About.
> >>
> >> -
> >> As an extension, given the flux of the VMs with the move to 64 bit,
> >> and ongoing support for both, it might also be good to have a "VM
> Version" field.
> >>
> >> Now actually I often find it awkward to report VM version.
> >> The text under System > System Reporter > VM General
> >> is quite bulky and its not clear what is the really useful parts for
> identification.
> >> So I usually end up pasting the whole thing, but this is too much for
> >> an issue tracker field. Also, there is no indication here of itimer
> versus threaded heartbeats which is sometimes pertinent.
> >> Could suitable minimal VM version info be added to System > About
> >> so the info required for the issue tracker is all in one simple place?
> >
> > Perhaps we should start by enumerating use cares. I originally wrote
> that bulky version info so that vm maintainers could identify the exact
> version of a VM. The use case here is to locate or obtain the build date,
> c compiler and exact C and VMMaker source for the vm in order to locate the
> exact vm, attach a debugger, recompile a matching debug vm, etc. At the
> time the version info was
> >
> > a) the commit to the subversion Cog repository of the vm sources
> >
> > b) the commit to the subversion squeakvm repository of the vm support
> files shared between Cog and squeakvm
> >
> > c) the VMMaker version of the StackInterpreter or CoInterpreter in the
> vm (including the "*" dirty mark if so)
> >
> > d) the VMMaker version of the Cogit in the vm (including the "*" dirty
> mark if so)
> >
> > With opensmalltalk-vm we can collapse a) and b), or rather, b) is no
> longer separate and hence obsolete, but the triad a), c) & d) are still
> most relevant to me. Condensing these to a summary means having to index
> (e.g. lookup the VMMaker info in opensmalltalk-vm by checking out a
> particular commit) and that's time consuming.
> >
> > So for me, while the info is poorly formatted and hard to read it is
> informative and saves me time. I'm happy to see it paired down by dropping
> b), and doing whatever we can to make it more readable but I'd still like
> to see people cite it in full when reporting a potential vm problem or
> reporting their vm version.
> >
> > What other use cases are there for this version info? (and that's not a
> rhetorical question).
> >
> >>
> >> -
> >> Finally, do we want these version fields to:
> >> * remain static for the version initially reported on, or
> >> * be refreshed as confirmed in a later version, or
> >> * have
