Open Stack

Excerpts from John Garbutt's message of 2015-06-01 12:26:48 +0100:
> 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.

It does communicate incompatibility, and it's not arbitrary (which is
what I was worried about if we just said we would bump the major version
each cycle automatically). So it makes sense to me as a reason to bump.

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

pbr generates versions like x.y.z.postN on each commit now, indicating N
commits since the x.y.z tag. So I think we're OK with version numbers
without having to do any tagging explicitly.

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