[Toybox] --version

[enh]

On Fri, Apr 17, 2015 at 7:31 PM, Rob Landley <rob at landley.net> wrote:
> 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?)

good idea. i've added "-android".

>> 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
> _______________________________________________
> Toybox mailing list
> Toybox at lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net



-- 
Elliott Hughes - http://who/enh - http://jessies.org/~enh/
Android native code/tools questions? Mail me/drop by/add me as a reviewer.

 1429396086.0