Excerpts from John Garbutt's message of 2015-06-01 12:26:48 +0100: > On 29 May 2015 at 22:38, Doug Hellmann <[email protected]> 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 > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
