Since there seems to be agreement, the change to require the bump has been posted to master branch[0]. Once backported and merged to the stable branch we can go ahead and release 13.1.0. -Julia [0]: https://review.opendev.org/#/c/687983/ On Fri, Oct 18, 2019 at 12:23 PM Sean McGinnis <sean.mcginnis@gmx.com> wrote:
Excluding known bad versions to efectively update the minimum constraint IS allowed by policy as far as I know (from a reqs team perspective). So this sgtm.
-- Matthew Thode
I agree, we should exclude the bad version in constraints. But we shouldn’t *only* do that as a way to side-step our other policies and raise the minimum version.
We don’t typically change the minimum version of a dependency just because of a bug fix. In this case, though, we have what sounds like a significant incompatibility, and IIRC we have allowed updates in the past to resolve those problems.
In this case, I think it’s safe to call the current dependency setting for sushy in the Ironic stable/train branch a bug (in ironic) and to allow that minimum to be updated without considering it a break in the stable policy, because Ironic is broken without the update.
+1, I think this should be fine for a stable backport.
The feature version bump will be a good indication to anyone picking it up that something (semi)significant has changed, so they should pay attention.
Might be a good idea to include a release note with the change to make sure it is called out in a way that consumers will be aware of the change.
Normally we would want the new release after the dependency update to be a feature update (the Y in X.Y.Z) because we haven’t added an incompatible dependency or changed the API but we have updated the dependencies. So, I think that means we will need an Ironic 2.1.0 release off of stable/train after the dependency is fixed (rather than 2.0.1 for a bug fix or 3.0.0 for a major update).
Doug