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