Open Stack

> >
> > 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
>
>
>