On 10/16/2015 04:23 AM, Thierry Carrez wrote:
> Robert Collins wrote:
>> [...]
>> BUT: we haven't (ever!) tested that the lowest versions we specify
>> work. When folk know they are adding a hard dependency on a version we
>> do raise the lower versions, but thats adhoc and best effort today.
>> I'd like to see a lower-constraints.txt reflecting the oldest version
>> that works across all of OpenStack (as a good boundary case to test) -
>> but we need to fix pip first to teach it to choose lower versions over
>> higher versions (https://github.com/pypa/pip/issues/3188 - I thought
>> I'd filed it previously but couldn't find it...)
>>
>> More generally, we don't [yet] have the testing setup to test multiple
>> versions on an ongoing basis, so we can't actually make any statement
>> other than 'upper-constraints.txt is known to work'. Note: before
>> constraints we couldn't even make *that* statement. The statement we
>> could make then was 'if you look up the change in gerrit and from that
>> the CI dvsm test run which got through the gate, then you can
>> figureout *a* version of the dependencies that worked.
>
> And that is the critical bit. The system we had in kilo and before may
> appear to be more practical to interpret downstream, but the assertions
> it was making were mostly untested. So the capping was a convenient
> illusion: things beyond the cap may be working, and things below the cap
> could actually be broken. At least the upper-constraints expresses
> clearly the combination that works and was tested. Combined with the
> uncapped requirements (which express what *should* be working, to the
> best of our knowledge), they make a more accurate, albeit admittedly
> more complex, set of information for downstream packagers.
And equally important is that pip only really reacts well to version
capping / pinning if you do it all at once across all your things.
When we had a cap, and raised it, we had to:
A) raise it in low level oslo libs (like oslo.config)
B) release those libraries with new caps
C) raise the cap in all the things that used that library
D) release those libraries with new caps
E) ... repeat
...
M) raise the cap in all top level openstack server projects
So a dozen library releases could easily be triggered by fixing one cap
or pin in one low level library, that were no functional changes, they
were just requirements changes. The only reason M could use the old
version of A is because pip wouldn't let you install the 2 together. Not
for any functional reasons.
-Sean
--
Sean Dague
http://dague.net
__________________________________________________________________________
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
