On Mon, Feb 24, 2014 at 1:58 PM, Anders Darander <[email protected]> wrote: > * Laszlo Papp <[email protected]> [140224 14:37]: > >> On Mon, Feb 24, 2014 at 1:18 PM, Burton, Ross <[email protected]> wrote: >> > On 24 February 2014 12:01, Laszlo Papp <[email protected]> wrote: >> >> For instance, the MeeGo Nokia phone had a software version information >> >> in the settings, and that is something I would personally consider as >> >> the image version, but again, there might be better ways. Please share >> >> good practices in here., or alternatively, feel free to point me to >> >> any documentation, examples, etc. > >> > This is an interesting example and a useful demonstration of why the >> > image version isn't always that useful. > >> I am not sure about that; see below. > >> > The software build number >> > covers *everything* that goes into the image, but the image version >> > number is just the version of the top-level image recipe. > >> The problem is that build numbers, that I have seen at least, are >> human unreadable. A human readable number would be nicer to have; >> something that I have just double checked on my Blackberry Limited >> Edition phone, and it is so that the OS Version is 10.0.10.738 in the >> settings. > >> Perhaps the build number can be made human readable... but currently, >> when I build an image, all I get is a long and not so convenient >> time-stamp. Is there a more gentle way of generating image version >> then? > > Human readable... I think that I've got to agree with Ross on this one. > > Though, the big question is about human readable... > > For our internal images, we're using > > IMAGE_PREPROCESS_COMMAND += "rootfs_update_timestamp ;\ > date +%Y%m%d%H%M >${IMAGE_ROOTFS}/etc/build ; \ > git describe --dirty --long --always > >${IMAGE_ROOTFS}/etc/version ;\ > " > > The first line is more or less the timestamp that you dislike. > > The git describe line is our main versioning. Using that line we get the > abreviated SHA1 of our repo, the last tag, the number of commits after > the last tag, and finally whether the repo was clean or dirty during the > build. > > This allows us internally to pinpoint the exact build setup (assuming > the build wasn't dirty, which it should never be on an autobuilder / > release build). > > It might not be as pretty as the 10.0.10.738 in your example, though for > us it's sufficient for the time being.
As you are writing, that is good for internal operation, but I would dislike providing such "versioning" for customers. _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
