On Mon, Feb 24, 2014 at 3:15 PM, Martin Jansa <martin.ja...@gmail.com> wrote: > On Mon, Feb 24, 2014 at 03:51:19PM +0100, Anders Darander wrote: >> * 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. > > in meta-webos we're appending human readable version suffix to > IMAGE_NAME, KERNEL_IMAGE_BASE_NAME and MODULE_IMAGE_BASE_NAME variables > and it's also included in some utils (like lsb and nyx-modules). > > That way we can distinguish not only what is in the image, but also > where the image was built (e.g. official/local build, > development/production version, which jenkins-job produced that etc).
Right, this sounds well-organized and advanced. Currently, we do not need this much flexibility, but it is useful to know there are people doing it as "professionally" as you. :-) _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
