[requirements][stable] Capping requirements in stable branches

Matthew Thode mthode at mthode.org
Thu Nov 28 06:27:14 UTC 2019


On 19-11-28 14:28:46, Akihiro Motoki wrote:
> On Thu, Nov 28, 2019 at 7:43 AM Matthew Thode <mthode at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20191128/b2583d06/attachment-0001.sig>


More information about the openstack-discuss mailing list