The Qiskit project is made up of several elements each performing different functionality. Each is independently useful and can be used on their own, but for convenience we provide this repository and meta-package to provide a single entrypoint to install all the elements at once. This is to simplify the install process and provide a unified interface to end users. However, because each Qiskit element has it’s own releases and versions some care is needed when dealing with versions between the different repositories. This document outlines the guidelines for dealing with versions and releases of both Qiskit elements and the meta-package.
For the rest of this guide the standard Semantic Versioning nomenclature will
be used of:
Major.Minor.Patch to refer to the different components of a
version number. For example, if the version number was
0.7.1, then the major
0, the minor version
7, and the patch version
The Qiskit meta-package version is an independent value that is determined by the releases of each of the elements being tracked. Each time we push a release to a tracked component (or add an element) the meta-package requirements, and version will need to be updated and a new release published. The timing should be coordinated with the release of elements to ensure that the meta-package releases track with element releases.
Neue Elemente hinzufügen¶
When a new Qiskit element is being added to the meta-package requirements, we need to increase the Minor version of the meta-package.
For example, if the meta-package is tracking 2 elements
qiskit-terra and it’s version is
0.7.4. Then we release a new element
qiskit-ignis that we intend to also have included in the meta-package. When
we add the new element to the meta-package we increase the version to
Patch Version Increases¶
When any Qiskit element that is being already tracked by the meta-package releases a patch version to fix bugs in a release we need also bump the requirement in the setup.py and then increase the patch version of the meta-package.
For example, if the meta-package is tracking 3 elements
qiskit-ignis==0.1.4 with the current version
0.9.6. When qiskit-terra release a new patch version to fix a bug
the meta-package will also need to increase it’s patch version and release,
Additionally, there are occasionally packaging or other bugs in the meta-package itself that need to be fixed by pushing new releases. When those are encountered we should increase the patch version to differentiate it from the broken release. Do not delete the broken or any old releases from pypi in any situation, instead just increase the patch version and upload a new release.
Minor Version Increases¶
Besides adding a new element to the meta-package the minor version of the meta-package should also be increased anytime a minor version is increased in a tracked element.
For example, if the meta-package is tracking 2 elements
qiskit-aer==0.1.1 and the current version is
0.7.5. When the
qiskit-aer element releases
0.2.0 then we need to increase the
meta-package version to be
0.8.0 to correspond to the new release.
Major Version Increases¶
Die Hauptversion unterscheidet sich von den anderen Versionen. Im Gegensatz zu den anderen Versionen, die im Sperrschritt mit jedem verfolgten Element aktualisiert werden, wird die Hauptversion nur erhöht, wenn alle verfolgten Versionen gestoßen werden (mindestens vor „1.0.0“). Im Moment haben alle Elemente noch eine Hauptversionsnummernkomponente von „0“ so lange bis jedes getrackte Element im Meta-Repository als stabil markiert wird, indem die Hauptversion auf „> = 1“ gesetzt wird. Bis dahin wird die Meta-Version die Paketversion der Hauptversion nicht erhöhen.
The behavior of the major version number component tracking after when all the elements are at >=1.0.0 has not been decided yet.
Qiskit Element Requirement Tracking¶
While not strictly related to the meta-package and Qiskit versioning how we track the element versions in the meta-package’s requirements list is important. Each element listed in the setup.py should be pinned to a single version. This means that each version of Qiskit should only install a single version for each tracked element. For example, the requirements list at any given point should look something like:
requirements = [ "qiskit_terra==0.7.0", "qiskit-aer==0.1.1", ]
This is to aid in debugging, but also make tracking the versions across multiple elements more transparent.
It is also worth pointing out that the order we install the elements is
critically important too.
pip does not have a real dependency solver which
means the installation order matters. So if there are overlapping requirements
versions between elements or dependencies between elements we need to ensure
that the order in the requirements list installs everything as expected. If the
order needs to be change for some install time incompatibility it should be
Qiskit has been designed with modularity in mind. It is extensible in many different ways; on the page, we highlight the ways in which the Qiskit community has engaged with Qiskit and developed extensions and packages on top of it.
The Qiskit base provider is an entity that provides access to a group of different backends (for example, backends available through IBM Quantum). It interacts with those backends to do many things: find out which ones are available, retrieve an instance of a particular backend, get backend properties and configurations, and handling running and working with jobs.
Decision diagram-based quantum simulator
Circuit optimization is at the heart of making quantum computing feasible on actual hardware. A central component of Qiskit is the transpiler, which is a framework for manipulating quantum circuits according to certain transformations (known as transpiler passes). The transpiler enables users to create customized sets of passes, orchestrated by a pass manager, to transform the circuit according to the rules specified by the passes. In addition, the transpiler architecture is designed for modularity and extensibility, enabling Qiskit users to write their own passes, use them in the pass manager, and combine them with existing passes. In this way, the transpiler architecture opens up the door for research into aggressive optimization of quantum circuits.
Extending Qiskit with new tools and functionality is an important part of building a community. These tools can be new visualizations, slack integration, Jupyter extensions and much more.