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