--version should mention some date

[jidanni]

toybox (e.g., find here) --version should mention some (copyright year even) date,
else the user has no idea how new it is.

$ which find|xargs ls -l
lrwxr-xr-x 1 root shell 13 2009-01-01 00:00 /vendor/bin/find -> toybox_vendor
$ find --version
toybox -be4de06abd23-android

Obviously 2009-01-01 00:00 can't be trusted,
and "-be4de06abd23-android" needs an online connection to look up what date it corresponds to.

[enh-google]

(in case you don't know, i'm the AOSP toybox maintainer...)

toybox (e.g., find here) --version should mention some (copyright year even) date,
else the user has no idea how new it is.

$ which find|xargs ls -l
lrwxr-xr-x 1 root shell 13 2009-01-01 00:00 /vendor/bin/find -> toybox_vendor
$ find --version
toybox -be4de06abd23-android

Obviously 2009-01-01 00:00 can't be trusted,

(to minimize OTA update size, all dates on the system image file system are set to 2009-01-01T00:00:00.)

and "-be4de06abd23-android" needs an online connection to look up what date it corresponds to.

this must be a fairly old version of Android? we stopped using the SHA years ago. these days it should look like this:

blueline:/ # find --version                                                    
toybox 0.8.3-android

which is a little misleading (it's "some point past 0.8.3", which is why the "-android") but more convenient than a SHA and at least a lower bound (which is handy in terms of "what features will i have?" but not so much for "which bugs will i have?"). coincidentally, one motivation[1] for removing the SHA was to minimize OTA update size. (even with binary diffing, every byte is precious when someone's paying for the bandwidth, plus every rewritten page of flash is wear and tear.)

i would leave this open for @landley to make the executive decision about adding a date ... except for the fact that even if he did, i'd immediately send him a patch so that Android could opt out of including it[2], for the same reasons we don't include a SHA. so it wouldn't help you anyway. you can tell because a non-Android toybox currently includes a SHA. here's a recent-ish one i have lying around on my desktop:

~/toybox-patch$ ./toybox --version
toybox 0.8.3-86-gd6a0b3031f0b

hopefully the toybox 0.8.3-android is good enough to get you in the right ballpark though.

longer-term i'd like to get toybox into the "runtime" mainline module. other than that the relevant unit of time is "years", i have no timeline for that. but "what toybox version am i running? the current one, of course!" seems like the fix to the real problem here :-)

---

1. another motivation is that the SHAs are from Android source trees, and so could be automerger SHAs or other non-useful SHAs, so having "a" SHA wasn't always useful anyway, unless you had access to the source tree that had been used to build your system image.
2. well, not necessarily: if it was like coreutils, say, where there's a copyright string that goes up each year, that would be fine. or if he just includes the date at which 0.8.3 happened, say, that would be fine too. but anything more like __DATE__ would have to go, and it's not obvious that "0.8.3 2020" helps anyone more than "0.8.3" especially given that it's never exactly 0.8.3 anyway.

[jidanni]

OK but with coreutils there still is the copyright date visible,

$ find --version
...
Copyright (C) 2019 Free Software Foundation, Inc.

Don't you guys have some kind of proper copyright like they have?

this must be a fairly old version of Android?

I'll tell you the date (2016) if you start telling me yours!

The user assumes that all this stuff is updated via Google Play "Android system" or whatever packages he sees everyday updating, and assumes bug reports will still be helpful.

That it is actually "baked" into the operating system and usually no longer updating is a surprise that could be eliminated by showing the copyright date upon --version.

[enh-google]

I'll tell you the date (2016) if you start telling me yours!

even better, i'll add all the rough version numbers to the docs:

https://android-review.googlesource.com/c/platform/system/core/+/1392868/1/shell_and_utilities/README.md

and assumes bug reports will still be helpful

i'd still rather people file bugs and we confirm that they're fixed at ToT than just assume they've been found and fixed in the intervening years.

That it is actually "baked" into the operating system and usually no longer updating is a surprise that could be eliminated by showing the copyright date upon --version.

yeah, i think that's covered by issue #50 which asks for --help/--version to be more like coreutils/busybox. i will point out though that you can't generally trust those dates either. here's what busybox on my desktop is saying right now:

~$ busybox --help
BusyBox v1.30.1 (Debian 1:1.30.1-4+build1) multi-call binary.
BusyBox is copyrighted by many authors between 1998-2015.

despite the fact that the internet says that version is from 2019-02.

[landley]

And I'm the non-AOSP maintainer of toybox.

There's no commit be4de06 in android's toybox github (freshly pulled), I'm guessing a vendor added a commit? Every vendor adds some change (https://rachelbythebay.com/w/2013/06/05/duck/) which is why a hash isn't sufficient: one commit added and you're completely lost. The date the binary was built (from 5 year old source) is uninteresting, and the date of the last commit (added to 5 year old source) isn't interesting either.

That's why the toybox build uses "git describe --tags" which in a fresh clone from the repository you're entering issues against currently says "0.8.3-113-g1d67afaf", I.E. since version 0.8.3 there have been 113 additional commits, ending with commit g1d. Even when your distro adds a few more at the end to mark its territory, I know roughly where that was in my tree.

The android repo has (its own) tags, and doing "git describe --tags" in my clone of the android repo says "android-r-beta-3-18-g4443a9f2" which is 18 commits after the "android-r-beta-3" tag, and if I do "git log --no-merges android-r-beta-3" the first commit there is from me so even though the android tree uses different tags, I still recognize where they tagged it and roughly how far we've come since then. And if the vendor adds their own tag, hopefully that's useful information, maybe containing a vendor name and model number in the tag name and then we can look it up and maybe find a repo to clone.

[jidanni]

Maybe say "Toybox installation: Enter vendor name ______ (required)" or something...
Anything to force xxxxx-ASUS-xxxxx to show up in the version string,
as else the user has no idea where to send reports to

• ASUS cellphone maker
• https://github.com/landley/toybox/ (hopefully now in --help)
• "Android feedback @ google" blackholes, etc.