@@ -145,3 +145,95 @@ so that they are documented but don't appear in the main index.
145145### API stability
146146
147147Reviews should point out where existing public APIs are broken.
148+
149+ ### Deprecation and API lifecycle
150+
151+ ` cuda.core ` follows SemVer (see `docs/source/:
152+
153+ - ** New APIs** may be added at any time (` x.Y.0 ` ).
154+ - ** Breaking removals** only happen in ** major releases** (` X.0.0 ` ).
155+ - Per the support policy, a deprecation notice must be present for ** at least
156+ one minor release** before the API is actually removed.
157+ - Changes should be notated in the code and also in the release notes in the
158+ "Deprecated APIs" section.
159+
160+ ** Annotating a new API** — Use the ` deprecated.sphinx.versionadded ` decorator:
161+
162+ ``` python
163+
164+ from deprecated.sphinx import versionadded
165+
166+ @versionadded (" 1.2.0" )
167+ def new_feature (...):
168+ """ Short description.
169+ """
170+ ```
171+
172+ Alternatively, if the vagaries of how we implement functions in Cython does not
173+ allow this, you can add the reST ` versionadded ` directive directly:
174+
175+ ``` python
176+ def new_feature (...):
177+ """ Short description.
178+
179+ .. versionadded:: 1.2.0
180+ """
181+ ```
182+
183+ ** Annotating a changed API** — Use the ` deprecated.sphinx.versionchanged ` decorator:
184+
185+ ``` python
186+
187+ from deprecated.sphinx import versionchanged
188+
189+ @versionchanged (" 1.2.0" , reason = " The old version was broken because..." )
190+ def new_feature (...):
191+ """ Short description.
192+ """
193+ ```
194+
195+ Alternatively, if the vagaries of how we implement functions in Cython does not
196+ allow this, you can add the reST ` versionchanged ` directive directly:
197+
198+ ``` python
199+ def new_feature (...):
200+ """ Short description.
201+
202+ .. versionchanged:: 1.2.0
203+ The old version was broken because...
204+ """
205+ ```
206+
207+ ** Deprecating an existing API** — use the ` @deprecated ` decorator from the
208+ ` Deprecated ` PyPI package (` deprecated.sphinx ` import name) and add a
209+ ` .. deprecated:: ` directive in the docstring. The decorator emits a
210+ ` DeprecationWarning ` at call time; the docstring directive surfaces it in the
211+ generated docs.
212+
213+ ``` python
214+ from deprecated.sphinx import deprecated
215+
216+ @deprecated (version = " 1.2.0" , reason = " Use `new_feature` instead." )
217+ def old_feature (...):
218+ """ Short description.
219+ """
220+ ```
221+
222+ Rules to follow when deprecating:
223+
224+ - The ` version= ` argument must be the ** first** in which the
225+ deprecation appears, not the release in which removal is planned.
226+ - The ` reason= ` string must name the replacement (if one exists) so users
227+ know what to migrate to.
228+ - Keep the old implementation fully functional — do not change its behavior,
229+ only add the decorator.
230+ - The deprecated API must remain in the codebase for ** at least one full minor
231+ release cycle** before it can be removed in a subsequent major release.
232+
233+ ** Removing a deprecated API** — removals land in a ** major release** . Before
234+ removing, verify that the deprecation has been present since at least the
235+ previous minor release. Remove the decorator, the implementation, and any
236+ ` __all__ ` entry; update ` api.rst ` and the release notes accordingly.
237+
238+ At some point in the future, we will provide automation for removal of
239+ deprecated APIs.
0 commit comments