Open Stack

On 29 May 2015 at 22:38, Doug Hellmann <doug at 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