Open Stack

On Fri, Feb 20, 2015, at 07:01 AM, Alan Pevec wrote:
> > (I believe the version cap for icehouse <2.4 is expected to a policy like this).
> 
> Yes, that assumed Semantic Versioning (semver.org) which 2.3.11 broke.

To elaborate, the issue here is that the dependencies between 2.3.10 and
2.3.11 changed, and that should have required at least a minor version
change.

The pbr docs include details about our use of SemVer [1], taken from the
upstream version and modified a bit based on what we and our distro
partners have more or less agreed on. I recommend all library
maintainers familiarize themselves with those policies because we're
building a lot of tooling in the CI infrastructure and elsewhere that
assumes that all libraries are following those rules. The section
relevant to this particular case is in the FAQ [2].

As Akihito points out elsewhere in the thread, it's a good idea to
increment the minor version for the first release at the beginning of
each cycle. We're moving to cap the requirements in stable branches
based on the SemVer rules, using the "next" minor version as the cap.
Incrementing the minor version for the first release in a cycle 
automatically puts the new release outside of the range of versions used
by the stable branches, and leaves the patch version series open for
actual bug fixes that need to be back-ported in clients and other
libraries. Version numbers are free, and we can easily get more of them.
:-)

That SemVer policy document is not exactly a page turner, and does get a
bit complicated in some of the interpretations of edge cases. If you are
preparing a library release and want to someone to double-check your
proposal for the next version number, ping me on IRC (dhellmann -- I'm
usually in openstack-dev and openstack-oslo, among other channels). I
will be more than happy to offer any advice I can.

Doug

[1] http://docs.openstack.org/developer/pbr/semver.html
[2]
http://docs.openstack.org/developer/pbr/semver.html#what-should-i-do-if-i-update-my-own-dependencies-without-changing-the-public-api
> 
> 
> Cheers,
> Alan
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev