[Toybox] --version

[Rob Landley]

On Fri, Apr 17, 2015 at 10:20 AM, Christopher Barry
<christopher.r.barry at gmail.com> wrote:
> 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...

Releases are important for reasons described in:

  https://www.youtube.com/watch?v=IKsQsxubuAA

If you don't have an hour to watch that video: releases give you
synchronization points where everybody sees the same behavior. Whether
that behavior's a bug or not, it gives you something stable and
reproducible. (Then having releases occur on a time based rather than
a feature-based schedule is cool for its own reasons, as the video
describes at length.)

The "continuous integration" fad is really about developers objecting
to how much work cutting and testing releases is, and how it involves
deadlines by which things either are or aren't ready, and how when
there's an inevitable bug found later it's a big deal, so they dowanna
do the work and they dowanna take the blame, they just want to
disappear into their development cave forever and never have to deal
with users and somehow automate away all the real work.

What it means for the rest of us is every single checkout you could
get a transient glitch that nobody noticed for 12 hours and only ever
really affected _you_. And it may not be as obvious as a build break,
it could be something subtle and complicated and horrible. (If
regression test suites were perfect, we wouldn't need to do new
development on the code they refer to, would we?)

In reality, continuous integration delegates the release work to
distros, who don't have as much domain expertise in that specific
package but need to actually support the result. Any package that does
that is a BAD PACKAGE from insane deveopers and should not be used if
there is ANY other alternative, but alas sometimes there isn't.

(Don't mince words, bones. Tell me what you really think.)

That said, new development _does_ happen between releases, it does so
with source control commit granularity, and the way you refer to a
commit is relative to your version control system. We're using
(goddess help us) git, so that means we refer to non-release versions
via commit number.

And _that_ said, look at commit 90afbad4c1f1 where I had the thing
check if we're using git and if so use the "git describe" output (12
digit hash version). So the current clean tree says:

  0.5.2-95-g517469767559

That's last tag 0.5.2, 95 commits on top of that, current hash 5174...
(I have no idea why it sticks in that useless "g", but there you have
it. Bragging rights I think.)

And all _that_ said, I suspect the best thing for the android guys to
do would be to tag their own "0.5.2-a1" or some such for android if
they don't plan to ship vanilla upstream releases, so when I get a bug
report I can at least see what they did. The "12 patches and a hash"
thing doesn't really tell me more than that. Unless I recognize the
magic hex string from repeated exposure, it doesn't tell me which tree
it came out of. (Android? Tizen? Gentoo?)

> Now that there is a more precise method, e.g. the hash, maybe that
> should be the only expression of 'version'.

Death first.

> It's hard for a human to tell the order of the versions with just a hash though.

Meh, humans, who cares about _them_. Humans hardly _ever_ come up in
software development, not remotely involved...

> Yet tag can
> be anything, not just an emulated maj/min/patch designator.

Releases have version numbers. This is not negotiable.

> e.g. --version
>
>  0.5.2-g0bfbb64
> OR
>  release-codename-g0bfbb64

An actual clean release won't indicate a git hash because people who
aren't using git should not have to care. If _we_ don't know what our
release versions are, we're flipping incompetent.

> So, each human-understanding-optimized version (release)

Because humans don't have to understand any of the development done
between releases?

> 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.

This requires the build to only ever be done it git. It deprecates the
concept of "release tarballs", and puts git in the hard build
dependencies for the project.

No.

Rob

 1429324294.0