* Laszlo Papp <lp...@kde.org> [140224 15:12]: > On Mon, Feb 24, 2014 at 1:58 PM, Anders Darander <and...@chargestorm.se> > wrote: > > * Laszlo Papp <lp...@kde.org> [140224 14:37]:
> >> On Mon, Feb 24, 2014 at 1:18 PM, Burton, Ross <ross.bur...@intel.com> > >> wrote: > >> > On 24 February 2014 12:01, Laszlo Papp <lp...@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. Or to get the number from a tag. 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. 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. Cheers, Anders -- Anders Darander ChargeStorm AB / eStorm AB _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
