[OE-core] No versioning for existing images

[Laszlo Papp]

On Mon, Feb 24, 2014 at 2:51 PM, Anders Darander <anders at chargestorm.se> wrote:
> * Laszlo Papp <lpapp at kde.org> [140224 15:12]:
>
>> 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:
>> >> 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?
>
>> > 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.
>
>
>> > 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.
>
> Yes, for customer communication it might very well be preferred to use
> some other version numbers.
>
> I'd guess that the best bet then would be to either store the version
> number in a config file in your repo, and have the build process take
> that number and put it into the image in a way similar to what's above.

Yes, I was thinking about a PRODUCT_VERSION or SOFTWARE_VERSION as a
configuration option (and/or command line option).

> Or to get the number from a tag.

Hmm, actually, this is not such bad an idea.

> In either case, you'll need to make
> sure that the release process updates the number correctly, thought that
> issue will be there no matter how you retreive and store the number.

Yes, these things can be automated in release scripts, absolutely.

> Though, I still think that having the info above on the images are
> usefull, not least when the customer comes back with more difficult to
> isolate issues.

I am not sure what information you mean. If you identify the image
appropriately with a version and the corresponding list of package and
versions (e.g. "image" BUILDHISTORY_FEATURE), I think you are good to
go.

Currently, I am not trying to solve such internal issues. It is more
important for me at this stage to be able to provide a useful version
to the end user and also for own sake, but admittedly, tag is actually
a good idea, thanks.