Jump to: navigation, search

Governance/Accepted/LibraryProjectDefinition

< Governance
Revision as of 00:00, 1 January 1970 by (talk)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Library Project Definition Proposal

Rationale

  • Client libs should be uploaded more frequently and as needed to PyPI
  • Client lib versioning should be tied to API version rather than server
  version
  • Client libs should always support previous versions of the API
  • Core projects should remain the things that comprise an OpenStack release
  and should be released together every six months
  • Additional projects, such as tempest, devstack are essential to the
  project and are part of the gating but are not themselves part of the
  release deliverable.

Proposal

  • Create two new catagories of projects, "library projects" and "gating
  projects"

Library Projects

  • Version based on latest API version declared supported. For instance:
    • python-novaclient 2.6.0.1 supports OpenStack Compute API v2.
    • When enough support has been added to support v3 and for us to declare
   that we're comfortable that it does, we'll update the major version to
   v3.
  • python-novaclient v3.0 should continue to fully support v2 APIs
  • Commits to trunk will need to be tested against previously released
   server versions in addition to trunk server versions
  • Single release sequence.
  • Automation will upload tagged versions directly to PyPI as needed
  • Client project will recycle/reuse PTL of associated server project

The following projects would be initially considered library projects:

  • python-novaclient
  • python-keystoneclient
  • python-quantumclient
  • python-glanceclient
  • python-swiftclient

openstack-common should be considered for addition whenever the code is ready to be imported as a library rather than using code copy.

Gating projects

  • Are driven by normal project tooling and process
  • Different from ecosystem projects in their essential relationship to our
  gating process, which means they themselves need to be gated
  • If, in the future, projects are removed from the gating mechanism,
  they should be removed from the gating projects list and become an
  ecosystem project again

The following project would be initially considered a gating project:

  • devstack
  • openstack.nose_plugin

Tempest should be added to the list as soon as we actually gate on it.