On 29 May 2015 at 22:38, Doug Hellmann <d...@doughellmann.com> wrote: > As with our other semver projects, we will use pbr’s interpretation of the > semver rules (http://docs.openstack.org/developer/pbr/semver.html) for minor > updates and patch releases. I don’t believe we discussed whether to increment > the major version during each cycle as we have been doing. Under the semver > rules that would indicate incompatibility, and we may not want to signal that > arbitrarily. We should discuss that further leading up to the M summit, when > we start preparing for the *next* cycle.
Given how Nova deals with upgrades, we basically want a way to say you need to upgrade to <kilo>.X before (live) upgrading to <liberty>.x (it allows us to drop some live upgrade compatibility code each release). I like the idea of bumping the major version to communicate that. Its not quite a "public API incompatibility" but its a very useful bit of information, with very similar consequences? But maybe that bends the semantics of semver too much? To be clear, I don't want 12 = liberty, it ties projects down to when they can indicate incompatibility. ttx's tool sound like it should fix the issues around that, to some extent. > We will still use stable branches, and stable release versions will follow > the same rules so it should always be clear what versions are upgrades of > what previous releases. Given the previous discussions on the stable branch, should we actually bump x automatically for every commit, where x is 12.0.x? For projects like Nova where we (currently loosely) consider every commit to be a release? Or maybe it should still be something like 12.0.0.a1.dev%(x)d, although that probably makes the six monthly milestones too prominent. > Please let me know if you think I missed any details, or misunderstood > something as agreed to. Or, of course, if you weren’t there and see something > wrong with the plan after looking at it now. I wasn't there, due to the Nova meetup at the same time, but I like the idea of adopting semver for the server projects. The old scheme was very much documenting the integrated release. Thanks, John __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
