Prepare 2.0.0 release (#14021)

This commit prepares the repo for the 2.0.0 release. It migrates all the release notes to a dedicated directory to differentiate those notes from future notes (this will need to be forward ported to the main branch), updates the version numbers to indicate it is the final 2.0.0 release, and updates the release notes to prepare them for publishing. Once this merges this commit should be used to tag the 2.0.0 release.

* Add prelude

* Edit renos a-b

* Edit more renos

* Fix code block indentation

* Update prelude

* Update remaining renos

* Attempt at fixing indentation issue

* Add missing renos

* Fix indentation?

* Apply suggestions from Becky's code review

* Apply inline suggestions from Matt's code review

Co-authored-by: Matthew Treinish <mtreinish@kortar.org>
Co-authored-by: Rebecca Dimock <66339736+beckykd@users.noreply.github.com>

* Apply content-related comments from Matt's code review

* Remove duplicated renos (1.3)

* Remove duplicated renos (1.4)

* Update prelude

* Undo oops

* Apply suggestion from Luciano's code review

Co-authored-by: Luciano Bello <766693+1ucian0@users.noreply.github.com>

* Update prelude and 64 bit reno

* Apply suggestions from Ray's code review

Co-authored-by: Raynel Sanchez <87539502+raynelfss@users.noreply.github.com>

* Fix typo in release notes

heirarchy -> hierarchy

This line is edited again to insert a version number in #14021 but I don't have the right to comment there.

* Add missing renos

* Add `box` release note

* Move reno and update release highlights with box

* Update version from rc2 to 2.0.0

* Minor edits

* Apply suggestions from Matt & Julien's code review

Co-authored-by: Matthew Treinish <mtreinish@kortar.org>
Co-authored-by: Julien Gacon <gaconju@gmail.com>

* Update releasenotes/notes/2.0/deprecate_arguments_and_deprecate_function-5e19f6f049fa489c.yaml

Co-authored-by: Matthew Treinish <mtreinish@kortar.org>

* Add rudimentary docs for BoxOp

* Fix sphinx formatting issues

* We don't see danger

* Final edits

* Fix lint

---------

Co-authored-by: Matthew Treinish <mtreinish@kortar.org>
Co-authored-by: Rebecca Dimock <66339736+beckykd@users.noreply.github.com>
Co-authored-by: Luciano Bello <766693+1ucian0@users.noreply.github.com>
Co-authored-by: Raynel Sanchez <87539502+raynelfss@users.noreply.github.com>
Co-authored-by: Albert Pool <albert.pool@dlr.de>
Co-authored-by: Jake Lishman <jake.lishman@ibm.com>
Co-authored-by: Julien Gacon <gaconju@gmail.com>

Author: 8 people

docs/conf.py

@@ -32,7 +32,7 @@
 # The short X.Y version
 version = "2.0"
 # The full version, including alpha/beta/rc tags
-release = "2.0.0rc2"
+release = "2.0.0"
 
 language = "en"
 

docs/release_notes.rst

@@ -10,4 +10,4 @@ Qiskit |version| release notes
     `:earliest-version:` should be set to the rc1 release for the current minor release series. For example, the stable/1.1 branch should set it to 1.1.0rc1. If on `main`, set to the prior minor version's rc1, like `1.0.0rc1`.
 
 .. release-notes::
-   :earliest-version: 1.1.0rc1
+   :earliest-version: 2.0.0rc1

qiskit/VERSION.txt

@@ -1 +1 @@
-2.0.0rc2
+2.0.0

qiskit/circuit/__init__.py

@@ -272,7 +272,8 @@
     * :class:`ForLoopOp`, to loop over a fixed range of values
     * :class:`IfElseOp`, to conditionally enter one of two subcircuits
     * :class:`SwitchCaseOp`, to conditionally enter one of many subcircuits
-    * :class:`WhileLoopOp`, to repeat a subcircuit until a condition is falsified.
+    * :class:`WhileLoopOp`, to repeat a subcircuit until a condition is falsified
+    * :class:`BoxOp`, to group a series of instructions for later processing
 
 :ref:`Circuits can include classical expressions that are evaluated in real time
 <circuit-repr-real-time-classical>`, while the QPU is executing a single shot of the circuit.  These
@@ -559,6 +560,8 @@
 
 .. autoclass:: Delay
     :show-inheritance:
+.. autoclass:: Duration
+
 
 The :class:`Barrier` instruction can span an arbitrary number of qubits and clbits, and is a no-op
 in hardware.  During transpilation and optimization, however, it blocks any optimizations from
@@ -708,9 +711,9 @@
 .. autofunction:: get_control_flow_name_mapping
 
 These control-flow operations (:class:`IfElseOp`, :class:`WhileLoopOp`,
-:class:`SwitchCaseOp` and :class:`ForLoopOp`) all have specific state that defines the branching
-conditions and strategies, but contain all the different subcircuit blocks that might be entered in
-their :attr:`~ControlFlowOp.blocks` property.
+:class:`SwitchCaseOp`, :class:`ForLoopOp` and :class:`BoxOp`) all have specific state that defines
+the branching conditions and strategies, but contain all the different subcircuit blocks that
+might be entered in their :attr:`~ControlFlowOp.blocks` property.
 
 .. autosummary::
     :toctree: ../stubs/
@@ -719,6 +722,7 @@
     WhileLoopOp
     SwitchCaseOp
     ForLoopOp
+    BoxOp
 
 The :class:`.SwitchCaseOp` also understands a special value:
 

qiskit/transpiler/passes/__init__.py

@@ -91,6 +91,7 @@
    Split2QUnitaries
    RemoveIdentityEquivalent
    ContractIdleWiresInControlFlow
+   LightCone
 
 Scheduling
 =============
@@ -225,6 +226,7 @@
 from .optimization import RemoveIdentityEquivalent
 from .optimization import Split2QUnitaries
 from .optimization import ContractIdleWiresInControlFlow
+from .optimization import LightCone
 
 # circuit analysis
 from .analysis import ResourceEstimation

qiskit/transpiler/passes/optimization/__init__.py

@@ -39,3 +39,4 @@
 from .split_2q_unitaries import Split2QUnitaries
 from .collect_and_collapse import CollectAndCollapse
 from .contract_idle_wires_in_control_flow import ContractIdleWiresInControlFlow
+from .light_cone import LightCone

releasenotes/notes/2.0/64-bit-only-4132f330ec7804b3.yaml

@@ -1,16 +1,12 @@
 ---
 upgrade:
   - |
-    Qiskit no longer supports Linux i686 and 32 bit Windows. Starting in Qiskit
-    2.0 a 64 bit platform is needed to run Qiskit. The user base for 32bit
-    architectures is relatively small and as Qiskit continues to focus on
-    improving performance to handle the increased scale in the complexity
-    of quantum computing hardware maintaining support for 32 bit platforms
-    is proving increasingly difficult. This coupled with the larger
-    scientific/numeric Python community's trend away from 32 bit platform
-    support maintaining support for 32bit platforms is no longer viable.
-    Qiskit 1.x will still continue to support 32 bit platforms, but starting
-    in this 2.0.0 release Qiskit no longer supports these platforms, will
-    not publish pre-compiled binaries for these platforms any longer, and
-    there is no longer any guarantee of being able to build from source on
-    32 bit platforms.
+    Qiskit v2.0 has dropped support for Linux i686 and 32-bit Windows. Starting in Qiskit
+    v2.0.0, a 64-bit platform is required to run Qiskit. 
+    This aligns with the trend in the scientific Python community and allows Qiskit to 
+    focus on performance improvements for increasingly complex quantum computing hardware.
+    
+    Qiskit v1.4 will continue to support 32-bit platforms until end-of-life (September 2025), 
+    but starting in this 2.0.0 release, Qiskit will no 
+    longer publish pre-compiled binaries for them, and offers no guarantee of 
+    successful source builds on 32-bit platforms.

releasenotes/notes/2.0/add-2q-fractional-gates-to-consolidate-blocks-pass-65fadda8ba17c831.yaml

@@ -1,9 +1,13 @@
 ---
 features_transpiler:
   - |
-    Added support for two-qubit fractional basis gates, such as :class:`.RZZGate`, to the
-    :class:`.ConsolidateBlocks` transpiler pass. The decomposition itself is done using the
-    :class:`.TwoQubitControlledUDecomposer`.
+    Added support for working with :class:`.Target` objects that contain two-qubit
+    basis gates that contain arbitrary angles, such as :class:`.RZZGate`, to the
+    :class:`.ConsolidateBlocks` transpiler pass. The pass previously would not
+    correctly estimate the number of gates required for a decomposition which
+    would result in blocks not being consolidated where :class:`.UnitarySynthesis`
+    could potentially optimize the block. Internally, the gate count estimate is
+    done using the :class:`.TwoQubitControlledUDecomposer` class.
 
     For example::
 
@@ -14,6 +18,7 @@ features_transpiler:
       qc = QuantumCircuit(2)
       qc.rzz(0.1, 0, 1)
       qc.rzz(0.2, 0, 1)
+      # basis_gates contains fractional gate (rzz)
       consolidate_pass = ConsolidateBlocks(basis_gates=["rz", "rzz", "sx", "x", "rx"])
       block = consolidate_pass(qc)  # consolidate the circuit into a single unitary block
       block.draw(output='mpl')

releasenotes/notes/2.0/add-2q-fractional-gates-to-unitarysynthesis-pass-f66eee29903f5639.yaml

@@ -1,9 +1,9 @@
 ---
 features_synthesis:
   - |
-    Add a :class:`.TwoQubitControlledUDecomposer` that decomposes any two-qubit unitary
+    Added a new :class:`.TwoQubitControlledUDecomposer` class that decomposes any two-qubit unitary
     in terms of basis two-qubit fractional gates, such as :class:`.RZZGate`
-    (or two-gates gates which are locally equivalent to :class:`.RZZGate` up to single qubit gates).
+    (or two-qubit gates that are locally equivalent to :class:`.RZZGate`, up to single qubit gates).
 
     For example::
 
@@ -33,5 +33,7 @@ features_transpiler:
       qc = QuantumCircuit(2)
       qc.append(unitary, [0, 1])
       dag = circuit_to_dag(qc)
+      
+      # basis_gates contains fractional gate (rzz)
       circ = UnitarySynthesis(basis_gates=['rzz', 'rx', 'rz']).run(dag)
       dag_to_circuit(circ).draw(output='mpl')

releasenotes/notes/2.0/add-bit-register-rust-979dd113aefb3563.yaml

@@ -11,8 +11,8 @@ upgrade_circuits:
     this as an implementation detail of the classes.
   - |
     It is no longer possible to create instances of the base :class:`.Bit` and
-    :class:`.Register` classes is no longer possible. Directly instantiating
-    these classes was clearly documented as something that was **not** supported
-    and being able to do it was was just an implementation artifact of how the
-    class heirarchy in previous releases. Starting in this release it is no longer
+    :class:`.Register` classes. Directly instantiating
+    these classes was clearly documented as something that was **not** supported,
+    and being able to do it was was just an implementation artifact of the
+    class hierarchy in previous releases. Starting in Qiskit v2.0.0, it is no longer
     possible to do this.