With the move to per-project requirements (aka divergent requirements) we started allowing projects to have differing exclusions and minimums. As long as projects still tested against upper-constraints we were good.
Part of the reason why we use upper-constraints is to ensure that project A and project B are co-installable. This is especially useful to distro packagers who can then target upper-constraints for any package updates they need. Another reason is that we (the requirements team) reviews new global-requirements for code quality, licencing and the like, all of which are useful to Openstack as a whole. If a projects dependencies are compatible with the global list, and the global list is compatible with the upper-constraints, then the projects' dependencies are compatible with the upper-constraints. All the above lets us all work together and use any lib listed in global-requirements (at the upper-constraints version). This is all ensured by having the check-requirements job enabled for your project. It helps ensure co-installability, code quality, python version compatibility, etc. So please make sure that if you are running everything in your own zuul config (not project-config) that you have the check-requirements job as well. -- Matthew Thode (prometheanfire)
signature.asc
Description: PGP signature
__________________________________________________________________________ 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
