mirror of
https://github.com/ansible-collections/community.general.git
synced 2025-07-25 06:10:22 -07:00
document our deprecation (#37788)
* document our deprecation fixes #37779 * Copy edit.
This commit is contained in:
parent
340064bfb9
commit
8b45cab3c1
1 changed files with 16 additions and 0 deletions
|
@ -133,6 +133,22 @@ maintainers will on fixes towards the release candidate.
|
||||||
Merging new features or fixes that are not related to the release candidate may
|
Merging new features or fixes that are not related to the release candidate may
|
||||||
be delayed in order to allow the new release to be shipped as soon as possible.
|
be delayed in order to allow the new release to be shipped as soon as possible.
|
||||||
|
|
||||||
|
|
||||||
|
Deprecation Cycle
|
||||||
|
`````````````````
|
||||||
|
|
||||||
|
Sometimes we need to remove a feature, normally in favor of a reimplementation that we hope does a better job.
|
||||||
|
To do this we have a deprecation cycle. First we mark a feature as 'deprecated'. This is normally accompanied with warnings
|
||||||
|
to the user as to why we deprecated it, what alternatives they should switch to and when (which version) we are scheduled
|
||||||
|
to remove the feature permanently.
|
||||||
|
|
||||||
|
The cycle is normally across 4 feature releases (2.x.y, where the x marks a feature release and the y a bugfix release),
|
||||||
|
so the feature is normally removed in the 4th release after we announce the deprecation.
|
||||||
|
For example, something deprecated in 2.5 will be removed in 2.9, assuming we don't jump to 3.x before that point.
|
||||||
|
The tracking is tied to the number of releases, not the release numbering.
|
||||||
|
|
||||||
|
For modules/plugins, we keep the documentation after the removal for users of older versions.
|
||||||
|
|
||||||
.. seealso::
|
.. seealso::
|
||||||
|
|
||||||
:ref:`community_committer_guidelines`
|
:ref:`community_committer_guidelines`
|
||||||
|
|
Loading…
Add table
Add a link
Reference in a new issue