-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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.4.0 release #13898
Prepare 1.4.0 release #13898
Changes from all commits
1c4255f
0ccb017
44955b8
65f9343
a4c0444
3c91504
02d8f95
0c876dd
ee157c9
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 |
---|---|---|
@@ -0,0 +1,208 @@ | ||
--- | ||
prelude: | | ||
The Qiskit v1.4.0 release is the final minor version release for the v1.x series. | ||
This release contains minimal features, and primarily adds new | ||
deprecation warnings for API changes coming | ||
in the future major version release v2.0.0. It is fully compatible with the | ||
Qiskit v1.3.x releases. It is strongly recommended that you upgrade from | ||
v1.3.x to v1.4.0 so that you're able to see the warnings about which | ||
interfaces will change with Qiskit 2.0.0. | ||
The v1.4.x release series will continue to be supported and receive | ||
bugfixes for 6 months and security fixes for 1 year after this | ||
release. The fixes will take place via patch releases. | ||
For more details on the release schedule and support cycle | ||
see: https://docs.quantum.ibm.com/start/install#qiskit-versioning | ||
which documents the release schedule in more detail. | ||
|
||
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. | ||
|
||
fixes: | ||
- | | ||
Fixed an issue in :meth:`.Target.has_calibration` and :meth:`.Target.get_calibration` | ||
where passing a parameterized Gate didn't work as expected. | ||
Refer to `qiskit/#11657 <https://github.com/Qiskit/qiskit/issues/11657>`__ and | ||
`qiskit/#11658 <https://github.com/Qiskit/qiskit/issues/11658>`__ for more | ||
information. | ||
|
||
deprecations_circuits: | ||
- | | ||
Subclassing :class:`.Register` or :class:`.Bit`, or any subclass of them | ||
(for example, :class:`.QuantumRegister` or :class:`~.circuit.Qubit`) is deprecated as of Qiskit v1.4.0. | ||
Subclassing these types was never explicitly supported by Qiskit, and its meaning was never defined. | ||
In Qiskit v2.0.0, the subclassing may become impossible due to technical limitations, | ||
and will certainly not be stored in a circuit. This is due to the move of the data model | ||
to the Rust space to improve performance. | ||
- | | ||
The ``dag`` optional parameter in the constructor of :class:`DAGNode` | ||
subclasses (namely :class:`DAGOpNode`), | ||
which has been unused and ignored since Qiskit v1.2.0, is now deprecated as of | ||
Qiskit v1.4.0 and will be removed in Qiskit v2.0.0. | ||
- | | ||
The Multiple-Control-Multiple-Target (MCMT) class in | ||
:class:`~qiskit.circuit.library.generalized_gates.MCMT` is now deprecated | ||
and replaced by :class:`.MCMTGate`, which is a proper :class:`.Gate` subclass. Using | ||
a gate instead of a circuit allows the compiler to reason about the object at a higher | ||
level of abstraction and unlocks the use of multiple synthesis plugins. | ||
- | | ||
The :mod:`qiskit.circuit.classicalfunction` module, and with it the | ||
:class:`.ClassicalFunction` class and its related :func:`.classical_function` | ||
and :class:`.BooleanExpression` utilities, have been deprecated as of | ||
Qiskit v1.4.0 and will be removed in Qiskit v2.0.0. | ||
|
||
This change is performed to avoid a | ||
dependency on the external library ``tweedledum``, which is no longer | ||
compatible with all of Qiskit's supported platforms and Python versions. | ||
For a similar functionality please use the :class:`.PhaseOracle` which | ||
is going to have an implementation that doesn't use ``tweedledum``, and | ||
the ``BitFlipOracle`` which will be added in Qiskit v2.0.0. | ||
|
||
Until ``BitFlipOracle`` is added, a phase-flip oracle can be converted | ||
to a bit-flip oracle by conditioning it on the result qubit, and applying | ||
Hadamard gates before and after the application of the oracle, as in the | ||
following example (where the oracle is on ``qr_x`` and the result is on ``qr_y``): | ||
|
||
.. code-block:: python | ||
|
||
from qiskit import QuantumRegister, QuantumCircuit | ||
from qiskit.circuit.library.phase_oracle import PhaseOracle | ||
|
||
bool_expr = "(x0 & x1 | ~x2) & x4" | ||
qr_x = QuantumRegister(4, "x") | ||
qr_y = QuantumRegister(1, "y") | ||
|
||
bit_flip_oracle = QuantumCircuit(qr_x, qr_y) | ||
phase_flip_oracle = PhaseOracle(bool_expr) | ||
controlled_phase_flip_oracle = phase_flip_oracle.control(1) | ||
bit_flip_oracle.h(qr_y) | ||
bit_flip_oracle.compose(controlled_phase_flip_oracle, qubits=[*qr_y, *qr_x], inplace=True) | ||
bit_flip_oracle.h(qr_y) | ||
|
||
print(bit_flip_oracle) | ||
|
||
Which results in | ||
|
||
.. code-block:: text | ||
|
||
┌───────────────┐ | ||
x_0: ─────┤0 ├───── | ||
│ │ | ||
x_1: ─────┤1 ├───── | ||
│ Phase Oracle │ | ||
x_2: ─────┤2 ├───── | ||
│ │ | ||
x_3: ─────┤3 ├───── | ||
┌───┐└───────┬───────┘┌───┐ | ||
y: ┤ H ├────────■────────┤ H ├ | ||
└───┘ └───┘ | ||
|
||
deprecations_providers: | ||
- | | ||
The :class:`.BackendV2Converter` class and :func:`.convert_to_target` functions | ||
have been deprecated in Qiskit v1.4.0 following the deprecation of :class:`.BackendV1`. | ||
:func:`.convert_to_target` is used to build a :class:`.Target` instance | ||
from a series of objects from the deprecated :class:`.BackendV1` workflow: | ||
:class:`.BackendConfiguration`, :class:`.BackendProperties` and :class:`.PulseDefaults`. | ||
:class:`.BackendV2Converter` is used for converting :class:`.BackendV1` | ||
to :class:`.BackendV2`, and cannot be maintained once :class:`.BackendV1` is removed. | ||
- | | ||
The :meth:`.BasicSimulator.run_experiment` method has been deprecated | ||
and will be removed in Qiskit v2.0.0. | ||
The method takes a :class:`.QasmQobjExperiment` as input argument, | ||
which has been deprecated together | ||
with the :class:`.Qobj` class and other related functionality. | ||
You can call :meth:`.BasicSimulator.run` | ||
with a :class:`.QuantumCircuit` input instead. | ||
|
||
deprecations_synthesis: | ||
- | | ||
The signature of the argument ``atomic_evolution`` in the constructor of the classes | ||
:class:`.LieTrotter`, :class:`.ProductFormula`, and | ||
:class:`.SuzukiTrotter` was modified in Qiskit v1.2.0 to improve the visualization | ||
of the output circuit. The older signature has now been deprecated in favor of the | ||
new alternative. From Qiskit 2.0.0, only the new alternative will be valid. | ||
|
||
To migrate, please modify the callable from | ||
``Callable[[Pauli | SparsePauliOp, float], QuantumCircuit]`` to | ||
``Callable[[QuantumCircuit, Pauli | SparsePauliOp, float], None]``. | ||
|
||
deprecations_transpiler: | ||
- | | ||
The :attr:`.DAGOpNode.sort_key`, :attr:`.DAGOutNode.sort_key`, and | ||
:attr:`.DAGInNode.sort_key` attributes have been deprecated and will be | ||
removed in the Qiskit v2.0.0 release. These attributes were originally used | ||
as a lexicographical key for topological sorting nodes in a | ||
:class:`.DAGCircuit`. However, the key is no longer used for this | ||
as the sorting is done internally in Rust code now. If you're using this | ||
attribute, you can recreate the key from the other attributes | ||
of a node. For example, you can use a function like:: | ||
|
||
def get_sort_key(node: DAGNode): | ||
if isinstance(node, (DAGInNode, DAGOutNode)): | ||
return str(node.wire) | ||
return ",".join( | ||
f"{dag.find_bit(q).index:04d}" for q in itertools.chain(node.qargs, node.cargs) | ||
) | ||
|
||
which will generate a string like the sort key does. | ||
- | | ||
The following uses of the :class:`.BackendProperties` object in the transpilation pipeline | ||
have been deprecated as of Qiskit v1.4.0 and will be removed in Qiskit v2.0.0: | ||
|
||
* ``backend_prop`` input argument in :class:`.DenseLayout` | ||
* ``properties`` input argument in :class:`.VF2Layout` | ||
* ``properties`` and ``coupling_map`` input arguments in :class:`.VF2PostLayout`. Note that ``coupling_map`` was only used in the presence of ``properties``. | ||
* ``backend_props`` input argument in :class:`.UnitarySynthesis` | ||
* ``backend_properties`` input argument in :class:`.PassManagerConfig` | ||
* ``backend_properties`` in :meth:`.Target.from_configuration` | ||
* ``backend_properties`` in :func:`.generate_routing_passmanager` | ||
* ``backend_properties`` in :func:`.generate_translation_passmanager` | ||
|
||
The :class:`.BackendProperties` class has been deprecated since Qiskit v1.2.0, together with | ||
other elements from the :class:`.BackendV1` workflow, and will be removed in Qiskit v2.0.0. | ||
The alternative path for communicating hardware information to the transpilation argument is the | ||
:class:`.Target` class, which can be set using the ``target`` input argument. | ||
Specific instruction properties such as gate errors or durations can be added to a :class:`.Target` upon | ||
construction through the :meth:`.Target.add_instruction` method. | ||
|
||
In the case of :func:`.generate_routing_passmanager` and :func:`.generate_translation_passmanager`, | ||
the ``backend_properties`` argument is optional and is superseded when the required ``target`` | ||
argument is populated. Usage of the argument can safely be removed in 1.x as long as you were | ||
passing in a target, which was the recommended use. | ||
|
||
- | | ||
The Pulse deprecation in Qiskit v1.3.0, included calibration builder passes | ||
such as :class:`.RXCalibrationBuilder`. The | ||
:class:`.NormalizeRXAngle` pass is a requirement of :class:`.RXCalibrationBuilder`; | ||
hence, it is being deprecated in Qiskit v1.4.0. The :func:`.rzx_templates` | ||
function in the calibration module is also being deprecated as it is not used in our codebase. | ||
|
||
deprecations_visualization: | ||
- | | ||
The parameters ``show_idle`` and ``show_barrier`` in the timeline drawers are | ||
deprecated as of Qiskit v1.4.0. The alternatives are, respectively, the | ||
``idle_wires`` and ``plot_barriers`` parameters, introduced in Qiskit v1.1.0, | ||
which are fully equivalent. | ||
The legacy parameter names will be removed in Qiskit v2.0.0. | ||
- | | ||
In Qiskit v1.4.0, the timeline drawer :func:`~qiskit.visualization.timeline.interface.draw` function | ||
will issue a deprecation warning if a ``target`` is not specified to get the duration | ||
of instructions. From Qiskit v2.0.0 on, ``target`` will be required and | ||
:func:`~qiskit.visualization.timeline.interface.draw` will fail if it is not specified. | ||
|
||
other: | ||
- | | ||
Passing ``property_set`` as an arbitrary keyword argument to the :meth:`~.BasePassManager.run` | ||
method of a subclass of :class:`.BasePassManager` will change behavior in Qiskit v2.0.0. It is | ||
currently forwarded to the internal representation converting functions of the pass manager, as | ||
is any arbitrary keyword argument to that method. Starting from Qiskit v2.0.0, the option will | ||
instead be used to set the seed of the :class:`.PropertySet` for the pipeline run, and the | ||
argument will not be passed to the conversion functions. | ||
|
||
This note only concerns implementers of subclasses of :class:`.BasePassManager` who have chosen | ||
their ``_passmanager_frontend`` and ``_passmanager_backend`` implementations to accept a | ||
keyword argument called ``property_set``. |
This file was deleted.
This file was deleted.
This file was deleted.
This file was deleted.
This file was deleted.
This file was deleted.
This file was deleted.
This file was deleted.
This file was deleted.
This file was deleted.
This file was deleted.
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.
We could use the plot directive for this instead. and get a graphical visualization. But it's not critical.