On 19-11-28 14:28:46, Akihiro Motoki wrote:

On Thu, Nov 28, 2019 at 7:43 AM Matthew Thode <mthode@mthode.org> wrote:

...

On 19-11-28 07:17:15, Akihiro Motoki wrote:

...

Hi,

I have a question on version capping in requirements files in stable branches.

When some newer version of dependent library does not work with my project, do we accept a patch to add version capping of the library in stable branches?

For example, the horizon team received a patch to novaclient to <16 [1]. novaclient 16.0.0 was released after Train release, so there is no surprise that we don't have the version cap novaclient<16 in Train release.

My understanding is that we don't usually cap versions of libraries after the release, but I am sending this mail to check our general guideline.

Thanks, Akihiro Motoki (irc: amotoki)

[1] https://review.opendev.org/#/c/693000/

You are correct, we don't cap generally, though I wonder if the tests allow it given that our goal is to maintian co-installability (through upper-constraints.txt) not have things be uncapped (that's a side effect of lowering the maintence burden in master).

Let me ask in detail more.

Is it true for stable branches? If the only reason of uncapping is to lower the maintenance cost in the master branch, I wonder we can allow capping in stable branches. It might help consumers who use OpenStack via PyPI directly.

For example, horizon train does not work with python-novaclient >= 16.0.0. Generally speaking, capping python-novaclient to <16 in train helps consumers.

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

...

We would not allow the cap in the reqs project, but it's possible it can work per-project.

In my understanding, we cannot do that unless a library is listed in blacklist.txt. Otherwise, requirements-check complains it even in stable branches.

Thanks, Akihiro

-- Matthew Thode

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.