Governance/Accepted/LibraryProjectDefinition

= Library/Gating 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.

Problems this solves

 * the ability to release a client library outside of the core project release cycle (requests have been coming in to our release manager for this)
 * the client libraries are already heading towards independence of the version of CORE api they're talking with
 * the ability to have a separate bug tracker for clients from the core projects

Proposal

 * Create two new categories of OpenStack projects in addition to Core 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.