Qiskit 1.0 release summary

ICYMI: As of February 15, the full Qiskit SDK 1.0 release is now available for installation via PyPI. This blog post will provide Qiskit users with a recap of the key points we originally shared about Qiskit 1.0 via our pre-release announcement in December, as well as new technical information on updates to Qiskit Runtime primitives, and a detailed list of the breaking changes users should be aware of. Be sure to keep an eye out for further communications coming later this year, which will celebrate the official launch of Qiskit’s first major version.

The TL;DR

Qiskit 1.0 is our way of marking the start of a new chapter in the history of quantum programming — one that is centered on performance, stability, and usability. But what does this mean exactly? We’ve made a variety of changes over the past few releases to prepare for this, including:

• A more performant SDK: Qiskit has spent years undergoing improvements to its overall performance, and this release represents the accumulation of many different improvements over the past 18 months. Qiskit 1.0 will enable users to easily build and transpile circuits with 100+ qubits, and lays the groundwork for future 1,000+ qubit workloads.
• A more stable API: With the launch of Qiskit 1.0, we are beginning a new, more stable release cycle and updating our versioning support. Get ready for less frequent breaking changes and much more robust backwards-compatibility and bug support than ever before!
• A leaner set of libraries: We’ve consolidated and focused the core features of Qiskit by removing the metapackage architecture and splitting out several modules into separate packages. This allows us to focus much more on stability and maintainability while enabling the wider open source community to contribute interesting new features. You’ll find more details on why and how we made this decision in our migration guide.
• An SDK built for an open-source ecosystem: The transpiler plugin interface and the broader Qiskit Ecosystem program are designed to encourage scientists, engineers and software developers to try their hand at building new extensions of Qiskit’s core capabilities, so we can all work together to advance the field of quantum computing.

New primitives design

One of the biggest changes that comes with Qiskit 1.0 is a redesign of the Sampler and Estimator primitives in the core SDK, as well as a new release of Qiskit Runtime that implements these updated definitions. These two interfaces play an essential role in enabling users to interact with quantum hardware through Qiskit.

The most significant new feature here is that we’ve introduced new Sampler and Estimator primitives, called SamplerV2 and EstimatorV2, that are designed to accept vectorized inputs. This allows users to perform sweeps over parameter value sets and observables, which in turn makes collecting the results of many combinations of circuits, expectation values, and parameters MUCH easier!

In this context, groups of circuits, parameters, and observables are called Primitive Unified Blocs (PUBs). The new primitives will accept multiple PUBs as input, and each PUB will get its own result — keeping everything contained in just a single runtime object.

Here’s a quick example of the new workflows this enables:

The new primitives also come with a few other changes, mainly:

• The estimator now possesses a precision argument in the run() method which specifies a targeted precision for the expectation value estimates.
• Similarly, the sampler has moved the shots argument from the options of the primitive definition into the arguments of the run() method.
• The new Sampler will also return the measurement outcome of every shot (in the order they were measured) instead of the (quasi-)probability distribution — allowing more flexibility in how you post-process the results from your jobs.

Native OpenQASM 3 support

Qiskit now offers an experimental native OpenQASM 3 parser to dump and load ‘QuantumCircuit’ objects. The parser has been overhauled and written in Rust, giving users the ability to load OpenQASM 3 instructions significantly faster. We’ve also removed the qiskit.qasm module and separated it into qiskit.qasm2 and qiskit.qasm3.

The example below shows how you can create a RealAmplitudes circuit with 20,000 instructions, dump it into a file, and then time how long the file takes to load. Users will need to pip install qiskit_qasm3_import to run the code block.

On a ThinkPad P1 (11th gen i7-11850H), the old parser takes approximately 7 seconds to load, while the new parser requires just over 200ms to execute. Quite the speedup!

At the moment, this fast parser is experimental and might not support all the instructions in the extensive OpenQASM 3.0 specification. Submit a feature request to let us know which instructions we should support next.

A generic fake backend module

The recent announcement of the new IBM® Quantum Heron processors and the IBM Quantum System Two™ design means Qiskit needs the ability to support dynamic circuits and disjoint qubit coupling maps. The 1.0 release includes this functionality along with a new GenericBackendV2 class within the qiskit.providers.fake_provider module.

This new class allows users to easily configure and build custom BackendV2 instances that can be run locally. The number of qubits, the coupling map, the basis gates, the instruction calibrations, the ability to run dynamic circuits (also known as control flow operations), and the measurement timestep can all be customized without manually constructing a Target object.

It’s important to note that we aren’t announcing full support for multi-QPU backends just yet. However, these new capabilities represent an important step towards that goal, and their rollout here means we’re on track in maintaining progress outlined in our roadmap.

See below for a quick example of the feature in action. We encourage you to experiment with this in your own workflows and start designing circuits to be run on disjoint qubit lattices.

A release lifecycle with more stability

The transition to Qiskit 1.0 also means the Qiskit SDK development cycle is changing. Instead of the frequent breaking changes of the 0.* era, there will now be a minimum of one year between major releases (where breaking changes will occur), and minor version releases will continue to occur as usual at a rate of once every three months.

More specifically, the Qiskit SDK is fully adopting the Semantic Versioning 2.0.0 design scheme, which is made up of three version components represented as major, minor, and patch versions (written as X.Y.Z). You’ll find a tentative release schedule below, which highlights the points at which these change will take place. Take a look at the corresponding docs page here if you’d like to learn more.

New major versions (the X in the X.Y.Z format) will come out once a year and will be the only release during our update cycle that will contain breaking changes to the Qiskit SDK. After a major release, the previous major version will be supported for an additional 6 months to allow folks time to transition between versions.

In between major versions, we’ll release minor versions (Y) approximately once every 3 months to deploy new backwards-compatible features or enhancements. Bug support for previous minor releases will come to an end once a new one is published, so be sure to keep your minor version updated! However, we don’t anticipate this will cause many issues for users because none of these releases will contain any breaking changes.

Finally, we’ll release patch versions (Z) to publish backwards-compatible bug fixes. These releases will only come out as needed when we identify bugs or other issues. No new deprecations, features, or public API changes will be made between these patch versions.

This new release cycle applies only to the Qiskit SDK — not other Qiskit technologies.

Memory & performance

Qiskit 1.0 comes with some hefty memory and performance improvements. However, we know it’s not enough to just say “Qiskit is more performant now!” and leave it there. So, let’s take a deeper look at how Qiskit 1.0 improves upon the performance of its predecessors. Here, we’ll focus on two main metrics: memory and speed.

In terms of speed, many features in Qiskit 1.0 are much faster now than they were in the past, due in large part to ongoing internal refactoring and the introduction of Rust code under the hood. For example, the transpiler in Qiskit 1.0 can bind and transpile circuits 16x faster than Qiskit 0.33, while also returning shorter circuit depths as an added bonus. The plot below depicts the amount of time required to bind the parameters of an EfficientSU2 circuit as the number of parameters increases using the 1.0 release, and compares that against the (0.45) release:

Similarly, when it comes to memory, we’ve done a lot of internal refactoring to reduce the footprint of circuits, with Qiskit 1.0 demonstrating an average 55% decrease in memory usage compared to Qiskit 0.39. The chart below shows data collected on the maximum memory used in building a 127-qubit Two Local circuit at increasing circuit depth, comparing the last three Qiskit versions against version 1.0:

Breaking changes

Here, we’ll highlight any changes that could cause users' existing code to break when updating to this latest version, such as deprecated classes/functions that have now been removed. This was motivated by a push to clean up and create a “leaner,” more trimmed down Qiskit. If there’s a particular change you want to learn more about, be sure to check our release notes and migration guide.

The change most likely to impact your projects is actually one found in the qiskit-ibm-runtime primitives, and is related to how jobs are submitted to our backends. Moving forward, Qiskit Runtime will require all circuits and observables users submit to employ only instructions supported by the system (referred to as Instruction Set Architecture or ISA). This essentially means you’ll have to make sure your circuits are transpiled against a backend and respect both its basis gates and coupling map. Otherwise, the job will fail.

There are also a number of smaller breaking changes in our migration guide that we think are worth highlighting in this post, including:

• Users can no longer import the qiskit.Aer object from qiskit. Instead, users must install the Qiskit Ecosystem package qiskit-aer, and then import qiskit_aer.Aer.
• Similarly, we’ve moved the qiskit.BasicAer module to qiskit.providers.basic_provider and renamed a few of its classes.
• We’ve removed the qiskit.execute() function. This was a wrapper around the run and transpile functionalities, so now you’ll have to run transpile — with the appropriate options — followed by backend.run().
• The method .QuantumCircuit.qasm should be replaced with either the qasm2.dump or the qasm3.dump (or, if you prefer strings as output, dumps()) method instead.
• A number of gate methods have been removed in favor of more established methods which accomplish the same thing:

Removed	Alternative
QuantumCircuit.cnot	QuantumCircuit.cx
QuantumCircuit.toffoli	QuantumCircuit.ccx
QuantumCircuit.fredkin	QuantumCircuit.cswap
QuantumCircuit.mct	QuantumCircuit.mcx
QuantumCircuit.i	QuantumCircuit.id
QuantumCircuit.squ	QuantumCircuit.unitary

• Additionally, the following gate methods have been removed and instead can only be applied using the QuantumCircuit.append method.

Removed	Alternative
QuantumCircuit.diagonal	DiagonalGate
QuantumCircuit.hamiltonian	HamiltonianGate
QuantumCircuit.isometry	Isometry
QuantumCircuit.iso	Isometry
QuantumCircuit.uc	UCCGate
QuantumCircuit.ucrx	UCRXGate
QuantumCircuit.ucry	UCRYGate
QuantumCircuit.ucrz	UCRZGate

• The QuantumCircuit.bind_parameters() method has been moved to QuantumCircuit.assign_parameters.
• The QuantumCircuit.snapshot has been replaced with qiskit-aer’s save instructions.
• We’ve removed the qiskit.converters.ast_to_dag. Previously it was used to convert the abstract syntax tree generated by OpenQASM 2. If you were using this, you can instead parse your OpenQASM 2 files into a QuantumCircuit using QuantumCircuit.from_qasm_file() or QuantumCircuit.from_qasm_string(), and then convert the QuantumCircuit into a DAG using .circuit_to_dag().
• The qiskit.extensions module has been removed. Most of its classes now belong to qiskit.circuit.library except for the following:
  • SingleQubitUnitary
  • Snapshot
  • ExtensionError
• Most of the qiskit.providers.fake_provider have been migrated into the new version of qiskit-ibm-runtime. For the most part you should be able to replace the import statement qiskit.providers.fake_provider with qiskit_ibm_runtime.fake_provider.
• We’ve removed the qiskit.pulse.library.parametric_pulses and many of the discrete pulse library objects.
• We’ve removed qiskit.quantum_info.synthesis and migrated its functionality to a few different locations, but most of them are now in qiskit.synthesis.
• We’ve removed the qiskit.tools module as most of its functionality was either replaced or could be found elsewhere. The primary exception here is the qiskit.tools.parallel_map() function which has been moved to qiskit.utils.
• We’ve moved a few items in the qiskit.transpiler.synthesis module to new locations:

Removed	Alternative
qiskit.transpiler.aqc (except for AQCSynthesisPlugin)	qiskit.synthesis.unitary.aqc
qiskit.transpiler.synthesis.graysynth	qiskit.synthesis.synth_cnot_phase_aam
qiskit.transpiler.synthesis.cnot_synth	qiskit.synthesis.synth_cnot_count_full_pmh

• The CrossTalkAdaptiveSchedule transpiler pass has been removed from Qiskit as it was no longer usable.
• The NoiseAdaptiveLayout transpiler pass has been removed and is superseded by VF2Layout and VF2PostLayout.
• We’ve removed the following qiskit.utils tools:
  • qiskit.utils.arithemetic
  • qiskit.utils.circuit_utils
  • qiskit.utils.entangler_map
  • qiskit.utils.name_unamed_args.
• We’ve removed qiskit.visualization.qcstyle. Users should instead use qiskit.visualizaiton.circuit.qcstyle as a direct replacement.

How to upgrade to Qiskit 1.0

If you are new to Qiskit and are just now joining us on your quantum journey, there’s no need to worry too much about all these changes. Just pip install qiskit and you’ll be ready to go!

For existing users, the situation is a bit more complicated. Qiskit 1.0 uses a new packaging structure, and you will not be able to upgrade an existing Qiskit 0.x installation to Qiskit 1.0 in-place. You’ll have to create a new conda/pip/poetry environment and add the dependency either as qiskit or qiskit>=1.0 to use the 1.0 release. This is the only time we expect to break packaging; you will be able to upgrade from Qiskit 1.0 and beyond in-place.

If you maintain a package that uses qiskit as a dependency, check out this section of the migration guide for guidance on how to transition your package to support Qiskit 1.0. And for users of projects that depend on Qiskit, please be patient with your maintainers! It’s a lot of work to support new versions of libraries, and it can take time to switch over.

For project maintainers, we recommend you first upgrade your dependency to 0.46 before refactoring your codebase to support 1.0. The 0.46 release includes quite a few new deprecation warnings and will likely make the transition to 1.0 smoother for your project. And don’t worry if you need extra time to deal with those deprecation warnings. With the new release cycle, you’ll have 6 months of full support for version 0.46.

Conclusion

So, there you have it — the most important details of the first stable version of Qiskit. We’ve only covered the main highlights of the changes here. If you’d like to learn more details, be sure to check out the release notes and migration guide to orient yourself to the new version.

Remember, if you want to put ideas forward for future versions of Qiskit, you can always open a GitHub issue to request a feature or report a bug. And if you want to follow what's coming up in the next releases, check out the Qiskit milestones here.

We are incredibly grateful to everyone who has taken the time over the past six-and-a-half years to contribute to Qiskit, and to everyone who has taken part in the work that has led us to this moment. Whether it was a pull request, bug report, or just a comment on slack, your contributions make a difference. Please keep it up! We are very proud of how far we’ve come, and can’t wait to embark on this next phase of our development journey with your continued support.

And as a special one-off to celebrate all of the work our open-source community has contributed over the years, we’d like to list and thank everyone who has contributed to this codebase since day 1. Whether your contribution was big or small, we are immensely appreciative of this community and all of the work you have done to help continue to improve Qiskit. We’d like to thank (in alphabetical order):

This blog post was written by Kaelyn Ferris with contributions from Abby Mitchell, Blake Johnson, Jake Lishman, Kevin Krsulich, Leron Gil, Luciano Bello and Robert Davis.