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:
python-novaclient===15.1.0
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
On Fri, 2019-11-29 at 11:01 -0600, Matt Riedemann wrote: the depency upstream with a backport of the scurity fix.