-
Notifications
You must be signed in to change notification settings - Fork 127
0.6 release notes and deprecation policy #1385
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
f99b279
12f9d25
8de4e04
f12c50c
db331c6
112f1e9
22812bc
afeeb81
b9fb13e
b817048
d720f6d
6d993f6
79f9265
553f502
931d05d
b57deb0
2cf403c
280bc1a
6641efa
5544899
5df6090
8edbd46
0d62d21
bfce4f1
e1ed9fb
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -74,7 +74,7 @@ When submitting a pull request for review, please ensure that: | |
etc.), you've added or updated a reno release note for that change and tagged the PR | ||
for the changelog. | ||
6. If your code requires a change to dependencies, you've updated the corresponding | ||
requirements file: `requirements.txt` contain core dependencies, | ||
requirements file: `requirements.txt` for core dependencies, | ||
`requirements-extras.txt` for dependencies for optional features, and `requirements-dev.txt` | ||
for dependencies required for running tests and building documentation. | ||
|
||
|
@@ -361,11 +361,48 @@ There are a few other build options available: | |
|
||
### Deprecation policy | ||
|
||
Qiskit Experiments is part of Qiskit and, therefore, the [Qiskit Deprecation | ||
Policy](https://github.com/Qiskit/qiskit/blob/main/DEPRECATION.md) fully applies here. | ||
Public-facing changes must come with a deprecation warning for at least three months or | ||
two version cycles before the old feature is removed. Deprecations can only happen on | ||
minor releases and not on patch releases. | ||
Any change to the existing package code that affects how the user interacts with the package | ||
should give the user clear instructions and advanced warning if the change is nontrivial. | ||
Qiskit Experiments's deprecation policy is based on [Qiskit's | ||
policy](https://github.com/Qiskit/qiskit/blob/1.0.0rc1/DEPRECATION.md) prior to its 1.0 release, but | ||
we impose less stringent requirements such that developers can iterate more quickly. | ||
Deprecations and feature removals can only happen on minor releases and not on patch releases. | ||
|
||
The deprecation policy depends on the significance of the user-facing change, which we have divided into | ||
three categories: | ||
|
||
A **core feature change** is one that affects how the framework functions, for example a | ||
change to `BaseExperiment`. The timeline for deprecating an existing core feature is as follows: | ||
|
||
* Minor release 1: An alternative path is provided. A `PendingDeprecationWarning` | ||
should be issued when the old path is used, indicating to users how to switch to | ||
the new path and the release in which the old path will no longer be available. The | ||
developer may choose to directly deprecate the feature and issue a `DeprecationWarning` instead, | ||
in which case the release note should indicate the feature has been deprecated and how to switch | ||
to the new path. | ||
* Minor release 2: The `PendingDeprecationWarning` becomes a `DeprecationWarning`, or the | ||
`DeprecationWarning` remains in place. The release note should indicate the feature has | ||
been deprecated and how to switch to the new path. | ||
* Minor release 3: The old feature is removed. The release note should indicate that the feature has | ||
been removed and how to switch to the new path. | ||
|
||
If the three-release cycle takes fewer than three months, the feature removal must wait for more | ||
releases until three months has elapsed since the first issuing of the `PendingDeprecationWarning` | ||
or `DeprecationWarning`. | ||
|
||
A **non-core feature change** may be a change to a specific experiment class or modules such as the | ||
plotter. The timeline is shortened for such a change: | ||
|
||
* Minor release 1: An alternative path is provided. A `DeprecationWarning` should be issued | ||
when the old path is used, indicating to users how to switch to the new path and the release | ||
in which the old path will no longer be available. | ||
* Minor release 2: The old feature is removed. The release note should indicate that the feature has | ||
been removed and how to switch to the new path. | ||
|
||
Lastly, a **minor, non-core change** could be a cosmetic change such as output file names or a | ||
change to helper functions that isn't directly used in the package codebase. These can be made in | ||
one release without a deprecation process as long as the change is clearly described in the | ||
release notes. | ||
Comment on lines
+364
to
+405
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is this documented in the user facing documentation? Personally I think ensuring the deprecation and stability policy are clear for end users too is important as it establishes user expectations and how to deal with potential api changes. For qiskit we put this here: https://github.com/Qiskit/documentation/blob/main/docs/start/install.mdx#L218-L290 which is the user facing documentation of the stability policy (which I still need to update qiskit's in-repo contributing guide to reflect the qiskit 1.0 changes) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Good point, added in 8edbd46. Might be time to split the Installation section out from Getting Started given its length. |
||
|
||
#### Adding deprecation warnings | ||
|
||
|
@@ -379,6 +416,7 @@ Utilities](https://docs.quantum.ibm.com/api/qiskit/utils) to add warnings: | |
@deprecate_func( | ||
since="0.5", | ||
additional_msg="Use ``new_function`` instead.", | ||
pending=True, | ||
removal_timeline="after 0.7", | ||
package_name="qiskit-experiments", | ||
) | ||
|
@@ -389,6 +427,12 @@ Utilities](https://docs.quantum.ibm.com/api/qiskit/utils) to add warnings: | |
pass | ||
``` | ||
|
||
Note that all warnings emitted by Qiskit Experiments, including pre-deprecation and deprecation | ||
warnings, will cause the CI to fail, but features up for deprecation should continue to be tested | ||
until their removal. For more information on how to use wrappers and test deprecated functionality, | ||
consult [Qiskit's | ||
policy](https://github.com/Qiskit/qiskit/blob/1.0.0rc1/DEPRECATION.md#issuing-deprecation-warnings). | ||
|
||
### Development cycle | ||
|
||
The development cycle for Qiskit Experiments is all handled in the open using project | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One of the reasons to still link to the Qiskit policy despite laying a mostly complete policy below is that the Qiskit policy has some good suggestions on how to implement deprecations. We might mention that here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, it's a bit awkward that we have our own usage examples but the Qiskit policy is more thorough. I pared down what we have currently to the QE specific
deprecate_func()
example and added a link to the relevant Qiskit policy section.