Open Stack

> The only issue is having a correct version number. Swift could well
> iterate after "20151", for example doing "20151.1" then "20151.2", etc.

Swift never had "coordinated" YEAR.N versions,
https://wiki.openstack.org/wiki/Swift/version_map
and they never released a version from their stable/* branches.
e.g. 2.2.1 and 2.2.2 are in Launchpad Series kilo
https://launchpad.net/swift/kilo
and were created from master branch, not stable/juno as one would expect.
I heard Swift team call them "Juno version released during Kilo cycle"
which confused me a lot but if you take into account that Swift master
is stable and always backward compatible, it does make sense.
In short, Swift is different enough so best not to force them into
coordinated point releases which is what we did.
And when you think of it more, Swift model should be the goal for all
OpenStack project: stable master, always backward compatbile, no
upgrade issues => no need for stable/* branches :)

>> So we could do what you're asking (option B) for Kilo stable releases,
>> but I think it's not really a viable option for stable/liberty onward.
>
> I fail to understand how version numbers are related to doing
> synchronized point releases. Sure, we have a problem with the version
> numbers, but we can still do a point release of all the server projects
> at once.

I don't see what value does the same tag across certain set of projects bring?
Taking it to the extreme, why don't you put the same version across
all packages in a distro?
Reality is that each openstack is independent and compatibility among
them is ensured by CI not by using the coordinated version tags.

> FYI, after a CVE, I have uploaded cinder with this version number:
> 2015.1.0+2015.06.06.git24.493b6c7f12-1

And with modified[*] plan D it would be 2015.1.25

> IMO, it looks ugly, and not comprehensive to Debian users. If I really
> have to go this way, I will, but I would have  not to.

You don't, if you'd support planD :)

> Though there's now zero guidance at what should be the speed of
> releasing server packages to our users.

Why there should be any guidance from upstream? Let your users tell
you and with planD you can update whenever requested fix is merged on
stable!

>> So I totally get that we should still have reference points to be able
>> to tell "this is fixed in openstack/nova stable/liberty starting with
>> 12.1.134post34" (or whatever we settle with). I totally get that any of
>> those should ship with relevant release notes. But that's about all I
>> think we need ?
>
> That's not a little thing that you're pointing at: having reference
> points is very important. But yeah, it may be the "only" thing... Like
> we will "only" loose track of what is fixed in which version. :(

On the contrary, with planD you'd have reference points and lots of them :)
And release notes would be generated from commit messages - this
requires better commit messages on stable branches but that's always
good. Here's how it would look like for current Cinder stable/kilo:
CHANGES
=======

2015.1.25
---------

* Disallow backing files when uploading volumes to image

2015.1.24
---------

* Dispose DB connections between backend proc starts

2015.1.23
---------

* Allow provisioning to reach max oversubscription
...

Cheers,
Alan


[*] modified plan D: automatically sign and push git tag after each
commit on stable branch. We get both, tags and tarballs in one go.