On Fri, Apr 17, 2015 at 7:31 PM, Rob Landley <[email protected]> wrote: > On Fri, Apr 17, 2015 at 10:20 AM, Christopher Barry > <[email protected]> wrote: >> On Fri, 17 Apr 2015 02:47:06 -0500 >> Rob Landley <[email protected]> wrote: >> >>>On Wed, Apr 15, 2015 at 12:51 PM, enh <[email protected]> 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 > [email protected] > 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. _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
