On 27 August 2015 at 02:15, Ihar Hrachyshka <ihrac...@redhat.com> wrote:
>> I really wish that nothing of this kind was even possible. Adding >> such an upper cap is like hiding the dust under the carpet: it >> doesn't remove the issue, it just hides it. We really have too much >> of these in OpenStack. Fixing broken tests was the correct thing to >> do, IMO. >> > > I think whoever is interested in raising a cap is free to send patches > and get it up. I don't think those patches would be blocked. So this is the situation. In Kilo we have only one mechanism to defend against new releases that are incompatible: version caps in project trees. Its possible but ugly and prone to confusing errors, to express 'only use versions up to Y to test this'. vs 'only use versions up to Y for this'[*] In Liberty we have constraints, which apply globally across all projects and give us a safety net, this will be available on stable/liberty once its created. So lifting the caps on kilo - won't work, please don't waste your own or others time trying. Lifing the caps on liberty - won't be needed, we're not putting them in in the first place. Folk like packagers that need to know the 'tested compatible versions of dependencies' will be advised to look in upper-constraints.txt. At the M summit I intend to drive discussion about getting the libraries back to a rolling release model, now that we're de-aggregating 'The Release' we're culturally aligning with these tree boundaries being contract boundaries, and working with any older supported release across those boundaries. If we can do that then one of the major drivers around caps will cease to be relevant (which was making sure that stable/server-X works with stable/library-Y even though there are newer releases of library-X up on PyPI. This stops being important if the statement we make isn't 'here is a release as a bundle' but is instead 'server-X uses library-Y and needed version a.b.c at release time'. There are obviously CI and API evolution factors at play: its not a simple or trivial discussion, but it is one strongly implied by non-lockstep releases of the servers. (IMO at least :)). *: The pitfalls are as follows: - projects can't express different rules in install_requires vs test-requirements.txt because of the requirements syncing checks - so the requirements have to be expressed in a non-synced file - even then, they can't be presented to pip twice or it will error, so you have to ensure that none of the testing does 'pip install -r requirements.txt -r test-requirements.txt -r thisnewfile ...' or it will bail, which means 'pip install -r test-requirements.txt -r thisnewfile' and let requirements.txt come in via the egg info reflection in pbr; which means url deps (deprecated anyway) won't work. - but devs can still be confused - and ordering issues can make surprising choices about dep versions done this way due to pips resolver limitations -- Robert Collins <rbtcoll...@hp.com> Distinguished Technologist HP Converged Cloud __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev