Re: Versioning of images

[Thomas Goirand <zigo@debian.org>]

On 12/19/18 12:30 PM, Bastian Blank wrote:
> Moin
> 
> We all know that versioning stuff is pretty hard problem.  I thought the
> current state would be okay, but with time I found some flaws in it.
> 
> What do we want from a version?
> 
> - A user should be able to tell what's in it, which we do by using a
>   date.
> - It should contain some monotonic increasing value to distinguish
>   between different builds on the same date.
> - Development builds should have something distinct in it.
> 
> We currently have:
> 
> - Amazon EC2 uses 2015-06-07-12-27, aka date plus time.
> - Google Cloud uses 20181219 and 20181219a.
> - MS Azure uses 20181219.0 or 201812190 for the internal version.
> 
> This version is part of our name, but also needs to follow some more or
> less strict rules by our providers in how it selects the latest image
> for an user:
> 
> - Amazon EC2 seems to not have any grouping of community images, nor
>   does it sort them in a particular way.  Apart from that it looks just
>   like a string.
> - Google Cloud just uses the last image added to an image family, the
>   image name itself is just a string and does not matter.
> - MS Azure uses a real versioning schema with a version consisting of
>   three 32-bit numbers.  The user usualy selects an image sku and gets
>   the image with the highest version available.
> 
> To accomodate this, I'll propose for the textual version:
> 
> - The first part of the version depends on the build type.
>   - For release images, it will be the current date as number (e.g.
>     20181219).
>   - For development images built on the CI, it will be the namespace (if
>     the repo is /waldi/debian-cloud-images, it will be "waldi").
>   - For development images built with make, it will be "manual".
> - The second part will be just the CI pipeline IID (the ID relative to
>   the current project, so it won't get too large).  This ID is automatic
>   and monotonic increasing for a particular project.
> 
> This gives as versions:
> 
> - 20181219.324
> - waldi.324
> - manual.0
> 
> This also maps easily into Azure versions:
> 
> - 0.20181219.324
> - 0.0.324
> 
> Regards,
> Bastian

Well, ok for testing, but for stable, I very much prefer what we
currently have for the OpenStack images. This means, having the Debian
release number, point release number, revision, and date. This means:

debian-9.6.1-20181206

Cheers,

Thomas Goirand (zigo)