Skip to content
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

Prepare 1.3.0 release #13447

Open
wants to merge 30 commits into
base: stable/1.3
Choose a base branch
from
Open

Conversation

raynelfss
Copy link
Contributor

@raynelfss raynelfss commented Nov 15, 2024

  • Move loose release notes.

Summary

The following commits set the version number on stable/1.3 to 1.3.0 in preparation for the 1.3.0 final release.

Details and comments

The following commits will:

  • Set the version number to 1.3.0.
  • Consolidate any loose release notes into the releasenotes/notes/1.3/ folder.
  • Update the cargo dependencies.
  • Fix any typos, broken links, and bad references in the folder releasenotes/notes/1.3/.
  • Include a prelude release note for the release.

@raynelfss raynelfss added on hold Can not fix yet Changelog: None Do not include in changelog labels Nov 15, 2024
@raynelfss raynelfss added this to the 1.3.0 milestone Nov 15, 2024
@raynelfss raynelfss requested a review from a team as a code owner November 15, 2024 20:11
@qiskit-bot
Copy link
Collaborator

One or more of the following people are relevant to this code:

Copy link
Collaborator

@beckykd beckykd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lots of good stuff! let me know if you have any questions!

@raynelfss
Copy link
Contributor Author

I have checked all release notes to the best of my abilities now. @beckykd feel free to further review these. I should be posting the prelude release note sometime tomorrow.

@raynelfss raynelfss added the ci: test wheels Run the wheel-build scripts as an additional CI run for this PR label Nov 20, 2024
Copy link
Collaborator

@beckykd beckykd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I'm through everything! Thanks for putting them all together and doing that initial edit!

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure what the term "inlined" means. Can you rephrase?
"inlined onto the base circuit"

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe it's just mentioning how it's realigning new instructions onto a base circuit. Maybe the word re-align works better?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"Inline" is a compiler term

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But also I think that note is from some prior release?

releasenotes/notes/1.3/storage-var-a00a33fcf9a71f3f.yaml Outdated Show resolved Hide resolved
releasenotes/notes/1.3/storage-var-a00a33fcf9a71f3f.yaml Outdated Show resolved Hide resolved
releasenotes/notes/1.3/storage-var-a00a33fcf9a71f3f.yaml Outdated Show resolved Hide resolved
releasenotes/notes/1.3/storage-var-a00a33fcf9a71f3f.yaml Outdated Show resolved Hide resolved
@raynelfss raynelfss force-pushed the prepare-1.3 branch 2 times, most recently from 6dffa85 to b1e08f8 Compare November 25, 2024 16:11
Copy link
Member

@mtreinish mtreinish left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for doing this, I've done a quick first pass through the notes but I still need to read the rendered output in sphinx to see how the complete notes read. From this first pass though I have a few concerns before I feel this is ready to merge and subsequently tagging the release.

The first is there are some notes that are already published on prior releases we need to delete those files from the stable/1.3 branch in this PR to avoid duplicating them. You can just git rm these files, but please do an audit of all the notes in the rendered output to make sure none exist on https://docs.quantum.ibm.com/api/qiskit/release-notes/1.2 or https://docs.quantum.ibm.com/api/qiskit/release-notes/1.1

The second large concern is around how we're documenting performance improvements. We are very inconsistent about how we're reporting speedups across the board. A lot of synthesis functions are called out individually as having been ported to rust and citing a speedup factor. While for the transpiler passes only some do this, the basis translator stands out prominently as being one of the few that did this. If we're going to call these out as feature notes we should be consistent and ensure we do it for all of them. Or if we feel it's not important to document them individually as a long list it is probably better to consolidate the multiple notes into a single note for passes that lists out the passes we've ported to rust and they're generally faster. We should do the same thing for synthesis functions too. Personally I think a single large note documenting all of them is better for readers than doing a lot of small notes.

A smaller thing is I feel like many release notes were not checked over for completeness or correct categorization and we should ensure this is all correct before publishing the release notes.

@@ -6,7 +6,7 @@ features_circuits:
See :ref:`circuit-real-time-methods` for more in-depth discussion on all of these.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This note file needs to be deleted it was already released in 1.1.0.

Comment on lines 3 to 4
Qiskit version 1.3.0 brings in major performance and quality improvements
for the transpiler. The minimum required Python version is now 3.9.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What are the quality improvements?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With this, I was mainly referring to the refactoring of the circuit library and the many additions to the synthesis transpiler passes and plugins, all of which were aimed at better performance and quality of the transpiler. But I can change this if you believe it is not the best way of putting it.

Comment on lines 3 to 4
Qiskit version 1.3.0 brings in major performance and quality improvements
for the transpiler. The minimum required Python version is now 3.9.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd probably move this to the end since it's more just a secondary FYI and not a headline thing.

releasenotes/notes/1.3/prepare-1.3.0-7c45598775fc2bbf.yaml Outdated Show resolved Hide resolved
Comment on lines 21 to 22
* The deprecation of the Qiskit pulse module and all of its related components.
The pulse module and its functionality will be part of `Qiskit Dynamics <https://github.com/qiskit-community/qiskit-dynamics>`_.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Typically I wouldn't highlight this in the prelude. We have the full release notes and a dedicated deprecation section for this. The prelude is really just for the most important changes in the release and a deprecation normally doesn't fall into this in my opinion. The removal in 2.0 probably would though (although those release notes are going to be huge).

in the run options, the results from the backend will be treated as level 1
results rather as bit arrays (the level 2 format).
results instead of bit arrays (the level 2 format).
upgrade:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this really an upgrade note of a fix note? If it's an upgrade note we should explain the rationale behind the change, and also change the category to upgrade_primitives.

releasenotes/notes/1.3/add-qpy-v13-3b22ae33045af6c1.yaml Outdated Show resolved Hide resolved
releasenotes/notes/1.3/add-qpy-v13-3b22ae33045af6c1.yaml Outdated Show resolved Hide resolved
releasenotes/notes/1.3/add-qpy-v13-3b22ae33045af6c1.yaml Outdated Show resolved Hide resolved
Copy link
Member

@mtreinish mtreinish left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for updating things. I started with the updated prelude, it is looking much better. Just have some small wording suggestions or missing details in suggestions

improvements to the :class:`.HighLevelSynthesis` transpiler pass, which can now take
into account idle auxiliary qubits to find the best available decomposition for a given gate.
* The minimum supported Python version is now 3.9 as Python 3.8 went end of life in 2024-10. Official support for Python 3.13 support was also added in this release.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is missing a newline, probably from the web editor I used for my previous suggestions. Manually adding one line like this should fix the build error.

Suggested change
* The minimum supported Python version is now 3.9 as Python 3.8 went end of life in 2024-10. Official support for Python 3.13 support was also added in this release.
* The minimum supported Python version is now 3.9 as Python 3.8 went end of life in 2024-10. Official support for Python 3.13 support was also added in this release.

raynelfss and others added 20 commits November 27, 2024 14:18
Co-authored-by: Rebecca Dimock <[email protected]>
Co-authored-by: Julien Gacon <[email protected]>
Co-authored-by: Rebecca Dimock <[email protected]>
Co-authored-by: Matthew Treinish <[email protected]>
Co-authored-by: Matthew Treinish <[email protected]>
Co-authored-by: Matthew Treinish <[email protected]>
Co-authored-by: Julien Gacon <[email protected]>
Co-authored-by: Alexander Ivrii <[email protected]>
Co-authored-by: Matthew Treinish <[email protected]>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a reminder to delete this file instead of moving it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a reminder to delete this file instead of moving it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a reminder to delete this file instead of moving it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a reminder to delete this file instead of moving it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a reminder to delete this file instead of moving it.

results rather as bit arrays (the level 2 format).
upgrade:
results instead of bit arrays (the level 2 format).
upgrade_primitives:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For this note I would add a sentence to the end of this like:

If you were previously relying on this behavior you can manually
clear the metadata before calling :meth:`.BackendSamplerV2.run`
by calling `circuit.metadata.clear()`.

:class:`.GroverOperator`, but does not require you to choose the implementation of the
multi-controlled X gate, but instead lets the compiler determine the optimal decomposition.
Additionally, it does not wrap the circuit into an opaque gate and is
faster because fewer decompositions are required for transpilation.
Example::
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can use a plot directive here so the circuit is actually shown in the release note. You just need to change the print(grover_op.draw()) to grover_op.draw("mpl")

@@ -25,8 +25,8 @@ deprecations_providers:
backend.configuration().memory No representation
backend.configuration().max_shots No representation
(*) Note that ``backend.target.operation_names`` includes ``basis_gates`` and additional
(*) Note that :meth:`.Backend.target.operation_names` includes ``basis_gates`` and additional
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This isn't correct and won't resolve correctly. It would be ``:attr:` instead of meth because target is an attribute of backend. But sphinx won't be able to resolve this because target isn't a path it can find as it's an instance attribute. This was probably more correct before.

@@ -0,0 +1,53 @@
---
features_transpiler:
- |
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for consolidating these into a single note. I think you just need to unify the language here. We should just list out the passes that were ported and say they're faster in general. We don't need any of the specific details for each pass.

Comment on lines +7 to +16
* The :class:`.ConsolidateBlocks` pass will now run the equivalent of the
:class:`.Collect2qBlocks` pass internally if it was not run in a pass
manager prior to the pass. Previously,
:class:`.Collect2qBlocks` or :class:`.Collect1qRuns` had to be run before
:class:`.ConsolidateBlocks` for :class:`.ConsolidateBlocks` to do
anything. By doing the collection internally, the overhead from the pass
is reduced. If :class:`.Collect2qBlocks` or :class:`.Collect1qRuns` are
run prior to :class:`.ConsolidateBlocks,` the collected runs by those
passes from the property set are used and there is no change in behavior
for the pass. The pass now runs up to 3x faster than it did with Python.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Except for the last sentence this should be a separate note like it was before. This was documenting the new feature of the pass to run standalone without any of the collection passes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Changelog: None Do not include in changelog ci: test wheels Run the wheel-build scripts as an additional CI run for this PR
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants