[OE-core] No versioning for existing images

Martin Jansa martin.jansa at gmail.com
Mon Feb 24 15:15:10 UTC 2014


On Mon, Feb 24, 2014 at 03:51:19PM +0100, Anders Darander 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.
> 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).

Regards,

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20140224/21aaaf26/attachment-0002.sig>


More information about the Openembedded-core mailing list