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 <[email protected]>
Co-authored-by: Rebecca Dimock <[email protected]>

* 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 <[email protected]>

* Update prelude and 64 bit reno

* Apply suggestions from Ray's code review

Co-authored-by: Raynel Sanchez <[email protected]>

* 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 <[email protected]>
Co-authored-by: Julien Gacon <[email protected]>

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

Co-authored-by: Matthew Treinish <[email protected]>

* Add rudimentary docs for BoxOp

* Fix sphinx formatting issues

* We don't see danger

* Final edits

* Fix lint

---------

Co-authored-by: Matthew Treinish <[email protected]>
Co-authored-by: Rebecca Dimock <[email protected]>
Co-authored-by: Luciano Bello <[email protected]>
Co-authored-by: Raynel Sanchez <[email protected]>
Co-authored-by: Albert Pool <[email protected]>
Co-authored-by: Jake Lishman <[email protected]>
Co-authored-by: Julien Gacon <[email protected]>

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.

releasenotes/notes/2.0/add-bool-bitarray-ddc30e5280f21c67.yaml

@@ -1,5 +1,6 @@
 ---
 features_primitives:
   - |
-    Added :meth:`~BitArray.to_bool_array` method to :class:`~BitArray` class that returns the bit array 
-    as a boolean NumPy array. The ``order`` argument can be used to specify the endianness of the output array.
+    Added a new :meth:`~.BitArray.to_bool_array` method to the :class:`.BitArray` class 
+    that returns the bit array as a boolean NumPy array. The ``order`` argument can be 
+    used to specify the endianness of the output array.

releasenotes/notes/2.0/add-ctrl-flow-name-mapping-21842a23726e6e77.yaml

@@ -2,7 +2,8 @@
 features_circuits:
   - |
     Added a new :func:`.get_control_flow_name_mapping` convenience function that returns a 
-    mapping of Qiskit's control-flow operation names to their corresponding class. 
+    mapping of Qiskit control-flow operation names to their corresponding classes. 
+
     Example usage:
 
     .. code-block:: python

releasenotes/notes/2.0/add-dt-generic-backend-v2-822f8806517e5dd1.yaml

@@ -1,12 +1,14 @@
 ---
 features_providers:
   - |
-    Added the ability to set the ``dt`` property of :class:`.GenericBackendV2` in the class initializer
-    with a new ``dt`` argument. Example usage::
+    Added the ability to set the ``dt`` property of :class:`.GenericBackendV2` in the class
+    initializer with a new ``dt`` argument. Example usage::
 
       from qiskit.providers.fake_provider import GenericBackendV2
+
       backend = GenericBackendV2(
-        num_qubits=5, 
-        basis_gates=["cx", "id", "rz", "sx", "x"],
-        dt= 2.22*e-10, 
-        seed=42)
+        num_qubits = 5,
+        basis_gates = ["cx", "id", "rz", "sx", "x"],
+        dt = 2.22*e-10,
+        seed = 42
+      )

releasenotes/notes/2.0/add-estimate_duration-method-a35bf8eef4b2f210.yaml

@@ -1,7 +1,26 @@
 ---
 features_circuits:
   - |
-    Added a new method, :meth:`.QuantumCircuit.estimate_duration`, to compute
-    the estimated duration of a scheduled circuit output from the :mod:`.transpiler`.
-    This should be used if you need an estimate of the full circuit duration instead
-    of the deprecated :attr:`.QuantumCircuit.duration` attribute.
+    Added a new circuit method, :meth:`.QuantumCircuit.estimate_duration`, to estimate the duration of 
+    a scheduled circuit after transpilation. The circuit duration is estimated by finding the 
+    longest path on a scheduled circuit based on the durations provided by a given :class:`.Target`. 
+    This method only works for simple circuits that do not contain control flow or other classical 
+    feed-forward operations.
+
+    Use this method instead of the deprecated :attr:`.QuantumCircuit.duration` attribute if you need an estimate of the full circuit duration.
+
+    Example usage::
+
+      from qiskit import QuantumCircuit, transpile
+      from qiskit.providers.fake_provider import GenericBackendV2
+
+      backend = GenericBackendV2(num_qubits=3, seed=42)
+
+      circ = QuantumCircuit(3)
+      circ.cx(0, 1)
+      circ.measure_all()
+      circ.delay(1e15, 2)
+
+      circuit_dt = transpile(circ, backend, scheduling_method="asap")
+      duration = circuit_dt.estimate_duration(backend.target, unit="s")
+      print("Estimated duration: ", duration)

releasenotes/notes/2.0/add-light-cone-pass-6c56085734512e98.yaml

@@ -1,15 +1,13 @@
 ---
 features_transpiler:
   - |
-    Added a new transpiler pass, :class:`.LightCone` that is used
-    to get the lightcone of a circuit when measuring a subset of
-    qubits or a specific Pauli string.
-    For example if you had a circuit like:
+    Added a new transpiler pass, :class:`.LightCone`, that returns the lightcone of a 
+    circuit when measuring a subset of qubits or a specific Pauli string.
+
+    For example, for the following circuit:
 
         .. plot::
 
-          from qiskit.transpiler.passes.optimization.light_cone import LightCone
-          from qiskit.transpiler.passmanager import PassManager
           from qiskit.circuit import QuantumCircuit
 
           qc = QuantumCircuit(3,1)
@@ -21,8 +19,7 @@ features_transpiler:
 
           qc.draw("mpl")
 
-    running the pass would eliminate the gates that do not affect the
-    outcome.
+    running the pass would eliminate the gates that do not affect the outcome:
 
         .. plot::
            :include-source:

releasenotes/notes/2.0/add-max-block-width-arg-e3677a2d26575a73.yaml

@@ -1,10 +1,10 @@
 ---
 features_transpiler:
   - |
-    Added a new argument ``max_block_width`` to the class :class:`.BlockCollector`
-    and to the transpiler passes :class:`.CollectLinearFunctions` and :class:`.CollectCliffords`.
-    This argument allows to restrict the maximum number of qubits over which a block of nodes is 
-    defined. 
+    Added a new argument ``max_block_width`` to the :class:`.BlockCollector` class
+    and to the :class:`.CollectLinearFunctions` and :class:`.CollectCliffords` transpiler passes.
+    This argument allows you to restrict the maximum number of qubits over which a block of nodes 
+    is defined. 
 
     For example::
 

releasenotes/notes/2.0/add-option-collect-from-back-cde10ee5e2e4ea9f.yaml

@@ -1,10 +1,10 @@
 ---
 features_transpiler:
   - |
-    Added a new option, ``collect_from_back``, to 
-    :class:`~qiskit.transpiler.passes.CollectMultiQBlocks`.
+    Added a new option, ``collect_from_back``, to the
+    :class:`~qiskit.transpiler.passes.CollectMultiQBlocks` transpiler pass.
     When set to ``True``, the blocks are collected in the reverse direction, 
-    from the outputs towards the inputs of the circuit. The blocks are still
+    from the outputs toward the inputs of the circuit. The blocks are still
     reported following the normal topological order. 
     This leads to an additional flexibility provided by the pass, and 
     additional optimization opportunities when combined with a circuit 

releasenotes/notes/2.0/arm-linux-tier1-fa79edaabf565685.yaml

@@ -3,6 +3,7 @@ features:
   - |
     Support for the Linux aarch64 platform has been promoted to tier 1 support as documented in:
 
-    https://docs.quantum.ibm.com/guides/install-qiskit#operating-system-support
+    https://quantum.cloud.ibm.com/docs/guides/install-qiskit#operating-system-support
 
-    from its previous support level of tier 2 in the 1.x release series.
+    from its previous support level of tier 2 in the v1.x release series.
+