[openstack-dev] [all] [stable] No longer doing stable point releases

Thomas Goirand zigo at debian.org
Mon Jun 15 14:21:41 UTC 2015

On 06/10/2015 03:46 PM, Thierry Carrez wrote:
> The main issue with B is that it doesn't work well once server component
> versions start to diverge, which will be the case starting with Liberty.

Review that policy then.

> We already couldn't (with Swift using separate versioning), but we worked
> around that by ignoring Swift from stable releases. As more projects opt
> into that, that will no longer be a possible workaround.

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

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

>> This is really one of the things I think we want to get away from...
>> If *every* stable commit is treated with the seriousness of it
>> creating a release, lets make every commit a release.
>> This means that Debian may be using a (micro)patch release newer or
>> older than a different distro, but the key is that it empowers the
>> vendors and/or users to select a release cadence that best fits them,
>> rather than being tied to an arbitrary upstream community wide date.
> +1

FYI, after a CVE, I have uploaded cinder with this version number:

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.

> It also removes the stupid encouragement to use all components from the
> same date. With everything tagged at the same date, you kinda send the
> message that those various things should be used together. With
> everything tagged separately, you send te message that you can mix and
> match components from stable/* as you see fit. I mean, it's totally
> valid to use stable branch components from various points in time
> together, since they are all supposed to work.

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

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


Thomas Goirand (zigo)

More information about the OpenStack-dev mailing list