[Toybox] --version

[Christopher Barry]

On Fri, 17 Apr 2015 02:47:06 -0500
Rob Landley <rob at landley.net> wrote:

>On Wed, Apr 15, 2015 at 12:51 PM, enh <enh at google.com> wrote:
>> in ad602aa127e44eade76fbb05fd27ee8f5825282a you added a --version
>> that outputs a constant string defined in main.c. i just wanted to
>> point out that -- for the foreseeable future until toybox is "mostly
>> done" -- this means Android will pretty much always lie. we'll be
>> some random SHA ahead of that version. (right now, for example,
>> we're far ahead of 0.5.2 but will claim to be 0.5.2.)
>
>Yup. I don't really have a good answer to that.
>
>I suppose I can add plumbing that _if_ it's built from git (release
>tarballs aren't) then use the git describe --tags output, otherwise
>fall back to the VERSION file? Hmmm...

Mostly.

Maybe the notion of version as a major/minor/patch designation is
really a legacy construct/tradition from other versioning systems of
yore...

Now that there is a more precise method, e.g. the hash, maybe that
should be the only expression of 'version'. It's hard for a human to
tell the order of the versions with just a hash though. Yet tag can
be anything, not just an emulated maj/min/patch designator.

e.g. --version

 0.5.2-g0bfbb64
OR
 release-codename-g0bfbb64

So, each human-understanding-optimized version (release) name is the
tag, with the exact version the hash (as you mention above using
'describe'), but always use it - not just on git builds.

Generating the tarball creates the VERSION file in the tarball using
git describe --tags. A build looks for the VERSION file first, then
falls back to git describe --tags. VERSION is never in the git tree.

-C


>
>> you mention in the checkin comment that you don't trust yourself to
>> keep things up to date --- did you consider setting it in the
>> makefile instead and grepping the version out of the www/ directory?
>
>Yes, and I'm even less likely to remember to update it there.
>
>> or, if you plan on having an rpm spec file or equivalent, from there?
>
>I'm all for people packaging toybox in RPM. And in .deb. And in gentoo
>ebuilds for portage. And in pacman for arch. And in bitbake for
>openembedded and yocto and tizen. And in slack packages. And in
>buildroot. And maybe android apk works in there somehow, or ipkg or
>opkg. And apparently sabotage is creating one called "butch"...
>
>Am I having toybox depend on any of that? Nope.
>
>> _i_ don't care, but if people report toybox-on-Android bugs to you
>> rather than to me, you might have a confusing time with the current
>> setup.
>
>Good point.
>
>Try now?
>
>> even if you surrounded the #define with #ifndef, i'm not sure what
>> i'd set it to in the makefile. version numbers don't really make much
>> sense until you're old and stable. we still have trouble with strace
>> because although they're old they're still very much under active
>> development, and often in areas we need (such as aarch64 support) or
>> want (like the recent ioctl disambiguation improvements). so strace
>> --version is always a lie on Android too. (but strace doesn't ship as
>> part of the system image, so only a developer would ever notice and
>> hopefully they'd be looking at git log anyway.)
>
>I have static strace binaries at http://landley.net/aboriginal/bin for
>various architectures but I hadn't hugely noticed the need for regular
>version updates on them? (Modulo that time powerpc system calls
>changed...)
>
>> probably not going to be a problem -- i pretty much always have to
>> ask "what version of Android?" on any bug report anyway -- but i
>> thought i'd mention it.
>
>As long as I've added --version I might as well do it _right_, it's
>good to raise issues so I finish fixing the problem.
>
>Rob
>_______________________________________________
>Toybox mailing list
>Toybox at lists.landley.net
>http://lists.landley.net/listinfo.cgi/toybox-landley.net



--
Regards,
Christopher Barry

Random geeky fortune:
Do not apply to broken skin.

 1429284006.0