[OE-core] No versioning for existing images

[Anders Darander]

* Laszlo Papp <lpapp at kde.org> [140224 14:37]:

> On Mon, Feb 24, 2014 at 1:18 PM, Burton, Ross <ross.burton at intel.com> wrote:
> > On 24 February 2014 12:01, Laszlo Papp <lpapp at kde.org> 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.

Cheers,
Anders

-- 
Anders Darander
ChargeStorm AB / eStorm AB