Jump to: navigation, search

Difference between revisions of "Requirements"

(Review Criteria)
(Review Criteria)
Line 20: Line 20:
 
* project has api compat commitment/policy
 
* project has api compat commitment/policy
 
* apply the same considerations to transitive dependencies
 
* apply the same considerations to transitive dependencies
 +
* commit log message includes reasoning for update
  
 
Additionally, regarding upstream version
 
Additionally, regarding upstream version

Revision as of 21:34, 26 April 2013

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

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