On Mon, Feb 24, 2014 at 2:51 PM, Anders Darander <and...@chargestorm.se> 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.
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. _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
