On 2019-03-06 13:08:49 +0000 (+0000), Sean Mooney wrote:
On Tue, 2019-03-05 at 22:21 +0000, Jeremy Stanley wrote: [...]
If (arbitrary example) you only ever test neutron against the master branch state of neutron-lib and not against the released state of neutron-lib, then when it comes time to tag neutron for a new release there's a chance you've grown to expect some unreleased behavior change in neutron-lib which was introduced since its most recent release. Then when users attempt to deploy and run neutron it breaks because their installation of the most recent version of neutron-lib is still too old to support their installation of the most recent version of neutron.
well you could get around that by having the lower-constaints job use the pypi releases. by convention we run the full unittest suite in lower constrains so it might not be as much coverage as you might like but it should catch alot of incompatibilities. i personly woudl still want at least on voting tempest job that used the latest package and perferally the oldest package however we don't have the latter today. [...]
I guess my point was that if you're developing two interdependent projects in parallel which won't release at the same time, you need to be mindful that work to implement support for a new feature of one in the other includes a graceful fallback behavior so that deployments with already-released dependencies lacking that feature will still be usable (and resist the temptation to instead simply drop support for versions in which it does not appear). Yes, your lower-constraints unit testing helps ensure this is the case with imported libraries like neutron-lib (as long as you have sufficient coverage over calls you make into it, of course). -- Jeremy Stanley