Open Stack

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