Open Stack

Excerpts from Robert Collins's message of 2015-09-23 06:40:19 +1200:
> On 23 September 2015 at 00:43, Doug Hellmann <doug at doughellmann.com> wrote:
> > Excerpts from Robert Collins's message of 2015-09-22 15:16:26 +1200:
> >> Currently we don't provide specific guidance on what should happen
> >> when the only changes in a project are dependency changes and a
> >> release is made.
> >>
> >> The releases team has been treating a dependency change as 'feature'
> >> rather than 'bugfix' in semver modelling - so if the last release was
> >> 1.2.3, and a requirements sync happens to fix a bug (e.g. a too-low
> >> minimum dependency), then the next release would be 1.3.0.
> >>
> >> Reasoning about this can be a little complex to do on the fly, so I'd
> >> like to put together some concrete guidance - which essentially means
> >> being able to provide a heuristic to answer the questions:
> >>
> >> 'Is this requirements change an API break' or 'is this requirements
> >> change feature work' or 'is this requirements change a bugfix'.
> >
> > Also, for our projects, "is this requirements change being triggered by
> > a need in some other project that also syncs with the g-r list"?
> 
> I don't think that maps to semver though: which is why I didn't list
> it. I agree that the /reason/ for a change may be 'consistency with
> other OpenStack projects'. Until we've finished fixing up the pip
> facilities around resolution we can't really make the requirements
> syncing process more flexible - and even then its going to be really
> very tricky [e.g. how do you test 'oslo.messaging works with
> oslo.config version X when some other thing in devstack needs version
> Y > X] - proving individually varied lower bounds is going to be
> awkward at best if it depends on integration tests.
> ...
> >> We could calculate the needed change programmatically for this
> >> approach in the requirements syncing process.
> >
> > We also have to consider that we can't assume that the dependency
> > is using semver itself, so we might not be able to tell from the
> > outside whether the API is in fact breaking. So, we would need something
> > other than the version number to make that determination.
> 
> Agreed - while its unusual, a project can do both of major version
> bumps without backwards incompatibilities, and minor or patch version
> bumps that do include [deliberate] backwards incompatibilities.
> 
> > I've been encouraging the application of a simple rule precisely
> > because this problem is so complicated. The 4 reasons for updates
> > can get lost over time between a requirements update landing and a
> > release being created, especially with automatic updates mixing
> > with updates a project actually cares about.  We aren't yet correctly
> > identifying our own API breaking changes and differentiating between
> > features and bug fixes in all cases, so until we're better at that
> > analysis I would rather continue over-simplifying the analysis of
> > requirements updates.
> 
> So how about we [from a releases perspective] just don't comment on
> requirements syncs - let projects make their own assessment?

Most folks can't follow the relatively simple rules we have for
that now. We regularly have requests for patch releases for libs with
new features (with commit messages like "Add fancy new blah blah
feature") and we have, at least once, completely missed a backwards
incompatibility that required a major version bump.

> 
> I don't think 'pick minor' is a very useful heuristic - for many of
> our 0.x.y projects we're overstating the impact [since x here is
> major-before-stable-has-happened], for consumers of those we're
> underestimating.

Our use of these versioning rules is relatively new, and everyone
is still figuring it out.  I've been trying to encourage
simple-to-understand interpretations for all of the rules so we're
at least consistent, if not 100% correct. For requirements changes,
I considered that since one could not simply install the new version
of the library without also updating its dependencies, it was not
a patch release. And since the requirements updates haven't been
backwards-incompatible (as far as I have been able to tell in most
cases), they didn't require a major version update. So, the minor
version seemed right. That also produced a rule we could evaluate
for the case where the project itself did not request the requirements
update which, as you point out, isn't covered by semver directly.

Doug