> 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. __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
