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)
