Jump to: navigation, search


Revision as of 10:54, 6 February 2014 by Markmc (talk | contribs) (Review Criteria)

Adding a Requirement to an OpenStack Project

In order to add or change a Python dependency requirement of an OpenStack project, it must first be added to the openstack/requirements repository.

Add it to the 'test-requires' or 'pip-requires' files as appropriate and submit it for review.

The requirement specification should usually include both a lower and upper bound. The lower bound should reflect the oldest known version of the package which has the APIs required. An upper bound should be added based on a package's policy of release versioning with respect to incompatible API changes so that we avoid problems caused a future incompatible release.

Once the change to openstack/requirements has merged, the local pypi mirror will be updated and then the requirements file for the OpenStack project may be updated. The new requirement specification must match exactly what is in openstack/requirements.

Requirements Team

Changes to openstack/requirements are approved by the requirements-core team in Gerrit. If you have an interest in coordinating dependency package versions across all the OpenStack projects and vetting new dependencies for their suitability for inclusion, please start reviewing changes to openstack/requirements. As your gain experience and your reviews are found helpful, you may be asked to join the core team.

Review Criteria

Consider the following criteria when reviewing changes to openstack/requirements

  • license (Apache2, MIT, BSD are probably okay, Copyleft licenses may be okay depending on circumstances)
  • python3 compatibility (all new requirements should be python3 compatible)
  • active development
  • prefer items already packaged in distros
  • project has api compat commitment/policy
  • apply the same considerations to transitive dependencies
  • commit log message includes reasoning for update
  • commit log message includes information about the OpenStack project(s) using the requirement

Additionally, regarding upstream version

  • minor upstream version updates should be considered routine/cursory review
  • use of pre-release versions of things needs an explanation
  • requirements with a missing upper bound on < next major number are dangerous

Upper Version Bounds

See here for an example of the kind of considerations needed when deciding which upper version bound best reflects the project's API compat policy:

python-seamicroclient>=0.1.0 # you *never* plan to break the API
python-seamicroclient>=0.1.0,<0.2 # you plan to break the API during the 0.x series, but may release compatible 0.1.x releases
python-seamicroclient>=0.1.0,<1 # you plan to maintain API compat until you release 1.0 with breaking changes
python-seamicroclient>=0.1.0,<2 # you plan to maintain API compat even in 1.0, but will move to 2.x if you make API changes