stable:follows-policy¶

Application to current deliverables¶

• Barbican (Key Manager service): barbican

• Cinder (Block Storage service): cinder, cinderlib, os-brick, python-brick-cinderclient-ext, python-cinderclient

• Congress (Governance service): congress

• Designate (DNS service): designate, designate-dashboard, python-designateclient

• Glance (Image service): glance, glance-store, python-glanceclient

• Heat (Orchestration service): heat, python-heatclient

• Horizon (Dashboard): django_openstack_auth, horizon

• Ironic (Bare Metal service): ironic, ironic-inspector, ironic-lib, ironic-python-agent, python-ironic-inspector-client, python-ironicclient

• Keystone (Identity service): keystone, keystoneauth, keystonemiddleware, pycadf, python-keystoneclient

• Manila (Shared File Systems service): manila

• Murano (Application Catalog service): murano, murano-agent, murano-dashboard, python-muranoclient

• Neutron (Networking service): neutron-fwaas, neutron, neutron-dynamic-routing, neutron-lib, neutron-vpnaas

• Nova (Compute service): nova, python-novaclient

• Octavia (Load-balancer service): neutron-lbaas, neutron-lbaas-dashboard, octavia, octavia-dashboard, python-octaviaclient, octavia-lib

• Oslo (Common libraries): automaton, castellan, debtcollector, futurist, mox3, oslo.cache, oslo.concurrency, oslo.config, oslo.context, oslo.db, oslo.i18n, oslo.log, oslo.messaging, oslo.middleware, oslo.policy, oslo.privsep, oslo.reports, oslo.rootwrap, oslo.serialization, oslo.service, oslo.upgradecheck, oslo.utils, oslo.versionedobjects, oslo.vmware, oslotest, osprofiler, pbr, stevedore, taskflow, tooz

• Powervmstackers: ceilometer-powervm, networking-powervm, nova-powervm

• Sahara (Data Processing service): python-saharaclient, sahara, sahara-dashboard, sahara-extra, sahara-image-elements, sahara-plugin-ambari, sahara-plugin-cdh, sahara-plugin-mapr, sahara-plugin-spark, sahara-plugin-storm, sahara-plugin-vanilla

• Swift (Object Storage service): python-swiftclient, swift

• Zaqar (Message service): zaqar

Rationale¶

All OpenStack project teams can create stable branches, with the name of their choice. However, some of those branches do not follow the Stable branch policy: some approve backports that modify the behavior of the software, some backport new features, some do not actively backport significant bugfixes, some don’t monitor proposed backports, or monitor the CI system on their stable branches…

That creates confusion for packagers and deployers of our software, which no longer know what to expect from a stable branch. Having stable branches is no longer a guarantee of an up-to-date source of safe fixes.

To replace it, this tag is granted by the stable branch maintenance team only to deliverables which have stable branches maintained following the common Stable branch policy. This lets downstream users easily determine which projects adhere to the common rules, and expose what the common rules are to a wider audience. As a side-effect, it encourages more project teams to follow the policy.

Requirements¶

The tag can only be applied to software components of an OpenStack cloud (openstack, openstack-operations on the map) and associated libraries (openstack-libs). It is not meant be applied to SDKs (openstack-user) or deployment tools (openstack-lifecyclemanagement).

Deliverables must follow the Stable branch policy in all currently active stable branches.

Tag application process¶

Proposals to add or remove this tag must be reviewed by the Stable Branch Maintenance team prior to final approval by the Technical Committee.

Deprecation¶

The stable:follows-policy tag may be removed from deliverables at any time, when the Stable Branch Maintenance team considers that the deliverable repeatedly violated the Stable branch policy.