[OE-core] No versioning for existing images

[Laszlo Papp]

On Mon, Feb 24, 2014 at 1:58 PM, Anders Darander <anders at chargestorm.se> wrote:
> * 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.

As you are writing, that is good for internal operation, but I would
dislike providing such "versioning" for customers.