openstack
/
governance
Code Issues Proposed changes

Merge "Remove assert:follows-standard-deprecation tag"

This commit is contained in:
Zuul 2022-03-31 05:12:36 +00:00 committed by Gerrit Code Review
parent 430531fc28 2bfa1b7996
commit e017ed1980
3 changed files with 0 additions and 144 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

43
reference/projects.yaml
View File

@ -45,7 +45,6 @@ barbican:
repos:
- openstack/barbican
tags:
- assert:follows-standard-deprecation
- stable:follows-policy
ansible-role-atos-hsm:
repos:
@ -123,7 +122,6 @@ cinder:
repos:
- openstack/cinder
tags:
- assert:follows-standard-deprecation
- stable:follows-policy
cinder-specs:
release-management: none
@ -241,7 +239,6 @@ designate:
- openstack/designate
tags:
- stable:follows-policy
- assert:follows-standard-deprecation
designate-dashboard:
repos:
- openstack/designate-dashboard
@ -333,7 +330,6 @@ glance:
repos:
- openstack/glance
tags:
- assert:follows-standard-deprecation
- stable:follows-policy
glance-specs:
release-management: none
@ -373,7 +369,6 @@ heat:
repos:
- openstack/heat
tags:
- assert:follows-standard-deprecation
- stable:follows-policy
heat-agents:
repos:
@ -428,7 +423,6 @@ horizon:
repos:
- openstack/horizon
tags:
- assert:follows-standard-deprecation
- stable:follows-policy
ui-cookiecutter:
release-management: none
@ -541,13 +535,11 @@ ironic:
- openstack/ironic
tags:
- stable:follows-policy
- assert:follows-standard-deprecation
ironic-inspector:
repos:
- openstack/ironic-inspector
tags:
- stable:follows-policy
- assert:follows-standard-deprecation
ironic-inspector-specs:
release-management: none
repos:
@ -632,7 +624,6 @@ keystone:
repos:
- openstack/keystone
tags:
- assert:follows-standard-deprecation
- stable:follows-policy
keystone-specs:
release-management: none
@ -787,7 +778,6 @@ manila:
repos:
- openstack/manila
tags:
- assert:follows-standard-deprecation
- stable:follows-policy
manila-image-elements:
repos:
@ -1069,13 +1059,11 @@ neutron:
- openstack/neutron-fwaas
tags:
- stable:follows-policy
- assert:follows-standard-deprecation
neutron:
repos:
- openstack/neutron
tags:
- stable:follows-policy
- assert:follows-standard-deprecation
neutron-dynamic-routing:
repos:
- openstack/neutron-dynamic-routing
@ -1110,7 +1098,6 @@ neutron:
- openstack/neutron-vpnaas
tags:
- stable:follows-policy
- assert:follows-standard-deprecation
neutron-vpnaas-dashboard:
repos:
- openstack/neutron-vpnaas-dashboard
@ -1139,7 +1126,6 @@ nova:
repos:
- openstack/nova
tags:
- assert:follows-standard-deprecation
- stable:follows-policy
nova-specs:
release-management: none
@ -2073,16 +2059,12 @@ OpenStackSDK:
openstacksdk:
repos:
- openstack/openstacksdk
tags:
- assert:follows-standard-deprecation
os-client-config:
repos:
- openstack/os-client-config
os-service-types:
repos:
- openstack/os-service-types
tags:
- assert:follows-standard-deprecation
osc-lib:
repos:
- openstack/osc-lib
@ -2092,13 +2074,9 @@ OpenStackSDK:
requestsexceptions:
repos:
- openstack/requestsexceptions
tags:
- assert:follows-standard-deprecation
shade:
repos:
- openstack/shade
tags:
- assert:follows-standard-deprecation
liaisons:
tc_members: []
oslo:
@ -2651,7 +2629,6 @@ sahara:
repos:
- openstack/sahara
tags:
- assert:follows-standard-deprecation
- stable:follows-policy
sahara-dashboard:
repos:
@ -2672,37 +2649,31 @@ sahara:
repos:
- openstack/sahara-plugin-ambari
tags:
- assert:follows-standard-deprecation
- stable:follows-policy
sahara-plugin-cdh:
repos:
- openstack/sahara-plugin-cdh
tags:
- assert:follows-standard-deprecation
- stable:follows-policy
sahara-plugin-mapr:
repos:
- openstack/sahara-plugin-mapr
tags:
- assert:follows-standard-deprecation
- stable:follows-policy
sahara-plugin-spark:
repos:
- openstack/sahara-plugin-spark
tags:
- assert:follows-standard-deprecation
- stable:follows-policy
sahara-plugin-storm:
repos:
- openstack/sahara-plugin-storm
tags:
- assert:follows-standard-deprecation
- stable:follows-policy
sahara-plugin-vanilla:
repos:
- openstack/sahara-plugin-vanilla
tags:
- assert:follows-standard-deprecation
- stable:follows-policy
sahara-tests:
repos:
@ -2857,7 +2828,6 @@ swift:
- openstack/swift
tags:
- stable:follows-policy
- assert:follows-standard-deprecation
swift-bench:
repos:
- openstack/swift-bench
@ -2914,13 +2884,9 @@ Telemetry:
aodh:
repos:
- openstack/aodh
tags:
- assert:follows-standard-deprecation
ceilometer:
repos:
- openstack/ceilometer
tags:
- assert:follows-standard-deprecation
telemetry-specs:
release-management: none
repos:
@ -2931,8 +2897,6 @@ Telemetry:
panko:
repos:
- openstack/panko
tags:
- assert:follows-standard-deprecation
deprecated: xena
python-aodhclient:
repos:
@ -3098,18 +3062,12 @@ trove:
python-troveclient:
repos:
- openstack/python-troveclient
tags:
- assert:follows-standard-deprecation
trove:
repos:
- openstack/trove
tags:
- assert:follows-standard-deprecation
trove-dashboard:
repos:
- openstack/trove-dashboard
tags:
- assert:follows-standard-deprecation
trove-specs:
release-management: none
repos:
@ -3297,7 +3255,6 @@ zaqar:
- openstack/zaqar
tags:
- stable:follows-policy
- assert:follows-standard-deprecation
zaqar-specs:
release-management: none
repos:

100
reference/tags/assert_follows-standard-deprecation.rst
View File

@ -1,100 +0,0 @@
..
This work is licensed under a Creative Commons Attribution 3.0
Unported License.
http://creativecommons.org/licenses/by/3.0/legalcode
.. _`tag-assert:follows-standard-deprecation`:
===================================
assert:follows-standard-deprecation
===================================
This tag is part of the assert category of tags, which are assertions
made by the project team themselves about their maturity. One such assertion
(or self-imposed contract) is about under which conditions APIs and features
of a given service may be deprecated in the future.
The "assert:follows-standard-deprecation" tag asserts that the project will
follow standard feature deprecation rules as described here.
Application to current deliverables
===================================
.. tagged-projects:: assert:follows-standard-deprecation
Rationale
=========
End users of a given service need to know if a feature or an API they are
using and rely on will still be supported by the software tomorrow.
Operators and deployers of a given service want to be able to roll out code
and configuration changes asynchronously, and therefore rely on new code
working correctly with the existing config files.
At the early stages of development it's important to be agile, experiment,
and fail fast. At that point it's not reasonable to commit to support those
early mistakes forever. But as the project matures and gets more users that
rely on existing features, knowing under which conditions the project can
remove features, APIs or alter configuration options in the future becomes
important. It can be a factor in deciding if the project is stable and mature
enough for a specific use case.
Requirements
============
Project teams can apply this tag to services that they produce to assert that
they will follow the following process for end-user-visible or operator-visible
features deprecation:
#. Features, APIs or configuration options are marked deprecated in the code.
Appropriate warnings will be sent to the end user, operator or library user.
Code will be frozen and only receive minimal maintenance (just so that it
continues to work as-is).
#. A migration path will be documented for current users of the feature. An
email thread will be started on openstack-operators to determine how many
people are using the deprecated API or feature, and how costly the migration
plan is to implement. A migration path may be "stop using that feature":
the cost is then very related to the number of people using the feature
and how dependent they are to that feature.
#. If the deliverable is part of an Interop Working Group Guideline, the
project will check if the deprecated feature is part of the exposed
capabilities. If it is, the obsolescence date (see below) additionally
needs to take into account Interop WG capabilities deprecation schedule.
#. Based on that data, an obsolescence date will be set. At the very minimum
the feature (or API, or configuration option) should be marked deprecated
(and still be supported) in the next stable release branch, *and* for at
least three months linear time.
For example, a feature deprecated in November 2015 should still appear
in the Mitaka release and stable/mitaka stable branch and cannot be
removed before the beginning of the N development cycle in April 2016.
A feature deprecated in March 2016 should still appear in the Mitaka
release and stable/mitaka stable branch, and cannot be removed before
June 2016.
Features included in an intermediate release but not a coordinated release
may be deprecated in the next release of any type and must stay in place at
least 3 months after being deprecated before being removed in a release of
any type.
Note that this delay is a required minimum. For significant features, it is
recommended that the deprecated feature appears at least in the next *two*
stable release branches.
In addition, projects assert that:
* It uses an automated test to verify that configuration files are
forward-compatible from release to release and that this policy is not
accidentally broken (for example, a gating grenade test).
* No existing config options will have their meaning changed in such a way
that it would alter the software behavior or otherwise render an existing
config file broken.
Note: this tag can currently only be applied to services (type:service
deliverables). The tag definition may evolve in the future to include library
feature deprecation policy and be applicable to libraries as a result.

1
reference/tags/index.rst
View File

@ -12,5 +12,4 @@ Current tags
.. toctree::
:maxdepth: 1
assert_follows-standard-deprecation
stable_follows-policy