On Fri, Mar 17, 2017 at 7:47 PM, Sven Van Caekenberghe <s...@stfx.eu> 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 <esteba...@gmail.com> 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 <eliot.mira...@gmail.com> wrote: > > > > Hi Ben, > > > >> On Mar 16, 2017, at 8:32 PM, Ben Coman <b...@openinworld.com> 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 separate fields "Confirmed in {Image/VM} Version" to track tests. > >> > >> cheers -ben > >> > >> cheers -ben > > >
