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: 2015.1.0+2015.06.06.git24.493b6c7f12-1 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. :( Cheers, Thomas Goirand (zigo) __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
