IBM Delivers Qiskit 1.0 and Best Practices for Transitioning to It

After spending much of its December Quantum Summit discussing forthcoming quantum software development kit Qiskit 1.0 — the first full version — IBM quietly debuted the latest version (February 15) and recently provided advice for those looking to make the jump. IBM is likely to share more details on Qiskit 1.0 capabilities and early uses at IBM Think 2024 meeting being held in Boston on May 5/20-23. Two areas to watch for are elaboration on newer AI capabilities to make using Qiskit easier to use as well as examples of how early users are making use of them.

“In the past, each new Qiskit release introduced breaking changes that had the potential to interfere with a user’s code. Those releases occurred fairly often, about once every three months. Qiskit’s new release cycle addresses this problem by making a useful distinction between different types of releases. Qiskit will now publish major releases roughly once per year, minor releases on the traditional schedule of once every three months, and smaller patch releases that implement bug fixes between minor releases as needed,” according to an IBM research blog, (Best practices for transitioning to Qiskit SDK v1.0).

“This new release cycle will help make Qiskit more stable than ever before. The once-per-year major releases will now be the only Qiskit releases that contain breaking changes. In other words, today’s Qiskit v1.0 users won’t have to worry about breaking changes until it’s time to upgrade to Qiskit v2.0. Before that point, only minor and patch releases will be published, and any changes or features that are introduced will be fully backwards compatible.”

Getting to the 1.0 release is a milestone for Qiskit as it is for software tools generally. Moving forward, says IBM, “Qiskit will now follow a release cycle based on the widely-used Semantic Versioning scheme, where software releases are numbered using the “X.Y.Z” or “major.minor.patch” format (e.g., Qiskit’s first major version, Qiskit v1.0.0). If you haven’t yet made the move to Qiskit v1.0, this blog post will tell you everything you need to know to take full advantage of this new system and ensure your transition is a smooth one.”

This recent blog (Best practices for transitioning to Qiskit SDK v1.0) suggests many existing Qiskit users may be better off pursuing a somewhat cautious path, adopting v0.46 first, before tackling v1.0. Here’s an blog excerpt:

“So, the bottom line is, if you’re a developer depending on Qiskit v0.45 who is planning to transition to Qiskit v1.0 — and especially if you have packages that depend on Qiskit v0.45 — we strongly encourage you to try upgrading to v0.46 first. Pay close attention to the warnings you see in Qiskit v0.46 and take your time cleaning them up. As previously mentioned, you’ll have until August 2024 to migrate your code before Qiskit 0.46 is no longer supported.

“Note: If your Qiskit version is currently capped at v0.44 or any release published prior to that, you should consider first updating to Qiskit v0.45, and then to Qiskit v0.46.

Additionally, if you’re still dependent on qiskit-terra, consider that the qiskit metapackage only contained qiskit-terra since v0.45. Since then, depending on qiskit directly is the preferred approach, and doing so will ease your journey to v1.0.

“Once you’ve cleaned up all your deprecation warnings and feel you are ready to upgrade to Qiskit v1.0, be sure to first test your code with Qiskit SDK v1.0. Next, update your requirements.txt to support Qiskit v1.0, and from there you should be all set. Remember, you will not be able to upgrade an existing Qiskit v0.x installation to Qiskit v1.0 in-place. You’ll have to create a new conda/pip/poetry environment and install qiskit>=1.0 to use the v1.0 release.

“Now, if your code is used by many packages or by a relatively large user-base, you may want to consider offering dual support — i.e., writing your code to support both v0.46 and v1.0. For example if your current package is your_package 3.2, you can release your_package 4.0 with Qiskit v1.0 support and your_package 3.3 with Qiskit v0.46 support. Or, alternatively, you can release your_package 4.0 which can be run with Qiskit v0.46 AND Qiskit v1.0.”

IBM also posted a blog summarizing some of the key changes in Qiskit 1.0. Among the enhancements are new Sampler and Estimator primitives, called SamplerV2 and EstimatorV2, that are designed to accept vectorized inputs; new Qiskit Runtime; support for OpenCASM3 (experimental native OpenQASM 3 parser); and improved memory and performance. improvements.

IBM says 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.” (See slide below)

“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,” reports IBM

As noted IBM is likely to share more details on Qiskit 1.0 at IBM Think 2024. IBM is also likely to review progress on its two most recently announced QPUs, Condor (1121 qubits) and Hderon (133 qubits); the latter has been designed to be ganged together with other QPUs to scale up system size. See IBM roadmap below.

Stay tuned.