Prepare Qiskit 1.2.3 (#13256)

* Prepare Qiskit 1.2.3

* Copy edit new prose

Cargo.toml

@@ -3,7 +3,7 @@ members = ["crates/*"]
 resolver = "2"
 
 [workspace.package]
-version = "1.2.2"
+version = "1.2.3"
 edition = "2021"
 rust-version = "1.70"  # Keep in sync with README.md and rust-toolchain.toml.
 license = "Apache-2.0"

docs/conf.py

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

qiskit/VERSION.txt

@@ -1 +1 @@
-1.2.2
+1.2.3

qiskit/qpy/__init__.py

@@ -126,15 +126,15 @@
       of Qiskit >= 0.46.0 can be loaded.  If a version of Qiskit between 0.45.0 and 0.45.3 was used
       to generate the files, and the non-default argument ``use_symengine=True`` was given to
       :func:`.qpy.dump`, the file can only be read if the version of ``symengine`` used in the
-      generating environment was in the 0.11 or 0.13 series, but if the environment was created
+      generating environment was in the 0.11 or 0.13 series. However, if the environment was created
       during the support window of Qiskit 0.45, it is likely that ``symengine==0.9.2`` was used.
 
     * When the loading version of Qiskit is between 0.46.0 and 1.2.2 inclusive, the file can only be
       read if the installed version of ``symengine`` in the loading environment matches the version
       used in the generating environment.
 
     To recover a QPY file that fails with ``symengine`` version-related errors during a call to
-    :func:`.qpy.load`, first attempt to use Qiskit >= 1.2.3 to load the file.  If this still fails,
+    :func:`.qpy.load`, try first to use Qiskit >= 1.2.3 to load the file.  If this still fails,
     it is likely because Qiskit 0.45.x was used to generate the file with ``use_symengine=True``.
     In this case, use Qiskit 0.45.3 with ``symengine==0.9.2`` to load the file, and then re-export
     it to QPY setting ``use_symengine=False``.  The resulting file can then be loaded by any later

qiskit/qpy/common.py

@@ -312,7 +312,7 @@ def mapping_from_binary(binary_data, deserializer, **kwargs):
 
 
 def load_symengine_payload(payload: bytes) -> symengine.Expr:
-    """Load a symengine expression from it's serialized cereal payload."""
+    """Load a symengine expression from its serialized cereal payload."""
     # This is a horrible hack to workaround the symengine version checking
     # it's deserialization does. There were no changes to the serialization
     # format between 0.11 and 0.13 but the deserializer checks that it can't

releasenotes/notes/fix-qpy-symengine-compat-858970a9a1d6bc14.yaml

@@ -4,31 +4,31 @@ fixes:
     Fixed an issue with :func:`.qpy.load` when loading a QPY file containing
     a :class:`.ParameterExpression`, if the versions of ``symengine`` installed
     in the generating and loading environments were not the same.  For example,
-    if a QPY file containing :class:`.ParameterExpression`\ s was generated
+    if a QPY file containing :class:`.ParameterExpression` objects was generated
     using Qiskit 1.2.2 with ``symengine==0.11.0`` installed, Qiskit 1.2.2 with
     ``symengine==0.13.0`` installed would be unable to load it.
 
     Previously, an error would have been raised by ``symengine`` around this
     version mismatch. This has been worked around for ``symengine`` 0.11 and
-    0.13 (there was no 0.12), but if you're trying to use different versions of
+    0.13 (there was no 0.12). However, if you're trying to use different versions of
     ``symengine`` and there is a mismatch, this version of Qiskit still might not
     work.
 issues:
   - |
     Versions of Qiskit before 1.2.3 will not be able to load QPY files dumped
     using :func:`.qpy.dump`, even with ``version`` set appropriately, if:
 
-    * there are unbound :class:`.ParameterExpression`\ s in the QPY file,
+    * there are unbound :class:`.ParameterExpression` objects in the QPY file,
     * the ``use_symengine=True`` flag was set (which is the default in Qiskit >=
-      1.0.0) in :func:`.qpy.dump`,
+      1.0.0) in :func:`.qpy.dump`, and
     * the version of ``symengine`` installed in the generating and loading
       environments are not within the same minor version.
 
     This applies regardless of the version of Qiskit used in the generation (at
     least up to Qiskit 1.2.3 inclusive).
 
-    If you want to maximize compatibility with older versions of Qiskit, you
-    should set ``use_symengine=False``.  Newer versions of Qiskit should not
+    If you want to maximize compatibility with versions of Qiskit < 1.2.3, you
+    should set ``use_symengine=False``.  Versions of Qiskit >= 1.2.3 should not
     require this.
   - |
     QPY files from the Qiskit 0.45 series can, under a very specific and unlikely
@@ -38,7 +38,7 @@ issues:
     * the :class:`.QuantumCircuit` or :class:`.ScheduleBlock` to be dumped
       contained unbound :class:`.ParameterExpression` objects,
     * the installed version of ``symengine`` was in the 0.9 series (which was the
-      most recent release during the support window of Qiskit 0.45),
+      most recent release during the support window of Qiskit 0.45), and
     * the ``use_symengine=True`` flag was set (which was *not* the default).
 
     Later versions of Qiskit used during generation are not affected, because
@@ -59,4 +59,4 @@ upgrade:
     objects is tied to the symengine version used to generate it, and there is the potential
     for a future symengine release to not be compatible. This upper version cap is to prevent
     a future release of symengine causing incompatibilities when trying to load QPY files
-    using :class:`.qpy.load`.
+    using :func:`.qpy.load`.

releasenotes/notes/prepare-1.2.3-1386aaab85a3fde0.yaml

@@ -0,0 +1,6 @@
+---
+prelude: >
+    Qiskit 1.2.3 is a patch release fixing a problem in QPY that could cause files generated by
+    one Python environment to fail to load in a different Python environment, despite the format
+    supposedly being transferable.  This is related to differences in the version of the library
+    ``symengine``, which QPY should have protected against.