[OE-core] No versioning for existing images

[Anders Darander]

* Laszlo Papp <lpapp at kde.org> [140224 16:26]:

> 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]:

> >> > 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).

Well, if you set it as a variable, you can always use it in e.g. the
IMAGE_PREPROCESS_COMMAND, to store it to a suitable file in the image.
Just as I'm storing the output from git describe.

If you plan on keeping multiple image versions (which you should do at
least for released images), you likely should then append your version
number to the image names (and possibly some more info), or at least
store them in a versioned tree/repository for easy retrieval.

> > 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.

Well, there's always a risk, especially at smaller companies (though
I've seen it happened quite a few times also in larger ones), that a
release build isn't build on an autobuilder, but manually on a
developers machine. If that developer isn't carefull enough / a little
bit lazy, he/she migth reuse an existing build tree. If that tree's
dirty, you'll never be able to recreate the image...

That's one reason that I like to always add the git describe info to the
image. Though, not necessarily in a way such that the customer normally
will see it. 

Now that I'm re-reading your comment, there's another possibility that
can occur, no matter if your setting the PRODUCT_VERSION on command line
or in a recipe. If you set it and build, and afterwards make another
change, followed by a rebuild, the version number will be re-used. Sure,
this is more of a release process thing; though if there's some way to
detect this, it's nice to automate it. Buildhistory is one such thing,
at least as long as you make sure that all releases are built on the
same build box.

> 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.

Sure, I agree that using a more standard versioning scheme towards the
customer is a good idea. (The customer can't know which SHA1 precedes
which other, nor the sequence of tags). I'm merely argueing that keeping
both types of version numbers is pretty vital in my opinion. (Not least
after having been tasked to try to find out what a customer's customer
actually was running, no-one knew what version were being used. After
that incident, I'm always advocating to include as much info as possible).

Cheers,
Anders

-- 
Anders Darander
ChargeStorm AB / eStorm AB