On 23 September 2015 at 00:43, Doug Hellmann <d...@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 <rbtcoll...@hp.com> Distinguished Technologist HP Converged Cloud __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev