-
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 21 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 | ||
|
||
|
@@ -389,6 +426,15 @@ 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. All such expected warnings should be caught in tests: | ||
|
||
```python | ||
with self.assertWarns(DeprecationWarning): | ||
# Test something deprecated here | ||
``` | ||
|
||
### Development cycle | ||
|
||
The development cycle for Qiskit Experiments is all handled in the open using project | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -2,13 +2,37 @@ | |
encoding: utf8 | ||
default_branch: main | ||
sections: | ||
- [features, New Features] | ||
- [features, New Features, 1] | ||
- [features_expnew, New Experiments, 2] | ||
- [features_explib, Experiment Library Updates, 2] | ||
- [features_expclass, Experiment Class Features, 2] | ||
- [features_analysis, Analysis Class Features, 2] | ||
- [features_expdata, Experiment Data Features, 2] | ||
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. I tested with #1342 merged in. Just a note that its release note needs to be updated to go under a section after it is merged (assuming it merges before this PR). 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. Will do. I have to move the note to the |
||
- [features_curvefit, Curve Fit Features, 2] | ||
- [features_calibration, Calibration Features, 2] | ||
- [features_visualization, Visualization Features, 2] | ||
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. I like the sections. Do you think it is too much to add some for upgrade and fixes? When the list gets longer than a page, I find it gets overwhelming to read through. I think the categories you used for features also work but there could be one more category for packaging upgrades (Qiskit 1.0, providers, Python versions). Maybe those could go under "other"? The deprecated methods and options list might be split out into different sections if we had them (analysis, experiments, experiment class). If we did all those, maybe we would group deprecation notes as well though that list is fairly short. 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. Added in 5df6090 along with a Package Upgrades subsection. I ended up putting the removal notes in that subsection and keeping deprecation notes in its own section since I like them grouped rather than separated into sections, but I don't feel that strongly about it. |
||
- [issues, Known Issues] | ||
- [upgrade, Upgrade Notes] | ||
- [upgrade, Upgrade Notes, 1] | ||
- [upgrade_package, Package Upgrades, 2] | ||
- [upgrade_explib, Experiment Library Upgrades, 2] | ||
- [upgrade_expclass, Experiment Class Upgrades, 2] | ||
- [upgrade_analysis, Analysis Class Upgrades, 2] | ||
- [upgrade_expdata, Experiment Data Upgrades, 2] | ||
- [upgrade_curvefit, Curve Fit Upgrades, 2] | ||
- [upgrade_calibration, Calibration Upgrades, 2] | ||
- [upgrade_visualization, Visualization Upgrades, 2] | ||
- [deprecations, Deprecation Notes] | ||
- [critical, Critical Issues] | ||
- [security, Security Issues] | ||
- [fixes, Bug Fixes] | ||
- [fixes_package, Package Fixes, 2] | ||
- [fixes_explib, Experiment Library Fixes, 2] | ||
- [fixes_expclass, Experiment Class Fixes, 2] | ||
- [fixes_analysis, Analysis Class Fixes, 2] | ||
- [fixes_expdata, Experiment Data Fixes, 2] | ||
- [fixes_curvefit, Curve Fit Fixes, 2] | ||
- [fixes_calibration, Calibration Fixes, 2] | ||
- [fixes_visualization, Visualization Fixes, 2] | ||
- [developer, API Changes for Experiment Authors] | ||
- [other, Other Notes] | ||
template: | | ||
|
This file was deleted.
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.