Open Stack

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?

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.

-Rob

-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud