[requirements][stable] Capping requirements in stable branches
smooney at redhat.com
Fri Nov 29 18:06:25 UTC 2019
On Fri, 2019-11-29 at 11:01 -0600, Matt Riedemann wrote:
> On 11/28/2019 12:27 AM, Matthew Thode wrote:
> > For stable branch issues with projects not 'requirements' I'd refer you
> > to the stable policy / team (already tagged in the subject line). I
> > suspect that we'd need to know what the cap for each project / version
> > would be for each release (is it a major version bump?, minor?, etc).
> Capping is bad in general and we don't want to do it on stable branches.
> Capping one thing can lead to breaking something else, potentially
> transitively, which gets to be a huge mess to untangle and is what we
> (stable and QA teams) used to deal with all the time in OpenStack. This
> is why we have upper-constraints and downstream packagers/deployers
> should be following it as the blessed "this is what works and is tested
> upstream" version of packages.
> So right now upper-constraints on stable/train has:
> So anyone packaging downstream should be aware of this and not try to
> use python-novaclient > 15.1.0 with train versions of the services
> (horizon, heat, etc).
unfortunetly that advice is not always followed but i agree that in general
distros should try to follow upper-constraints where possible. for security
reasons sometime distros have to move to a newer version but that is rare.
in such cacses idealy the issue would be adress by another stable release of
the depency upstream with a backport of the scurity fix.
More information about the openstack-discuss