French
Langues
English
Japanese
German
Korean
Portuguese, Brazilian
French
  • Docs >
  • Stratégie de développement
Shortcuts

Stratégie de développement

Gestion des Versions

Le projet Qiskit est constitué de plusieurs éléments couvrant différentes fonctionnalités. Chacun des éléments a son utilité et peut être utilisé de manière indépendante, mais pour faciliter les choses nous fournissons une source et un meta-package servant de point d’entrée et permettant d’installer tous les éléments en une seule fois. Il s’agit de simplifier le processus d’installation et d’offrir une interface unique aux utilisateurs. Cependant dans la mesure ou chacun des éléments a ses propres versions, il faut apporter un minimum d’attention lorsque l’on gère les différentes versions de chacun des éléments. Ce document souligne les lignes directrices à observer pour gérer les différentes versions des éléments, et le meta-package.

Pour la suite de ce guide, la nomenclature standard de la gestion de version sémantique est la suivante Majeure.Mineure.Correctif pour référencer les différentes composantes du numéro de version. Par exemple si le numéro de version est 0.7.1, alors la version majeure est 0, la version mineure est 7, et le niveau de correctif est 1.

Version du Meta-package

La version du meta-package de Qiskit est une valeur indépendante qui est déterminée par les versions de chacun des éléments qui le constituent. A chaque fois que la mise mise à jour d’un élément est publiée (ou qu’un élément est ajouté), la définition du contenu du méta-package sera mise à jour et sa version sera changée. Les calendriers de mise à jours seront coordonnés pour s’assurer que les publications du méta-package sont consistantes avec les mise à jour des éléments.

Ajout de nouveaux éléments

Lorsqu’un élément de Qiskit est mis à jour ou ajouté et qu’il modifie les dépendances, nous augmentons la version Mineure du meta-package.

Par exemple supposons que le meta-package suit deux éléments qiskit-aer``et ``qiskit-terra et que sa version est 0.7.4. Puis nous publions le nouvel élément qiskit-ignis que nous voulons aussi suivre dans le meta-package, alors nous passons la version du meta-package à 0.8.0.

Incrément des version de correction

Lorsqu’un élément de Qiskit déjà suivi dans le méta-package fait l’objet d’une modification pour corriger des problèmes, alors les exigences doivent apparaître dans le fichier setup.py et cela va incrémenter la version du méta-package.

Par exemple, supposons que le méta-package suit 3 éléments qiskit-terra==0.8.1, qiskit-aer==0.2.1, et qiskit-ignis==0.1.4 à la version 0.9.6. Lorsque qu’une correction sera apportée à qiskit-terra pour corriger un problème, ce dernier passera à la version 0.8.2, le méta-package sera également incrémenté et son niveau deviendra 0.9.7.

De plus, il peut arriver de manière occasionnelle qu’il soit nécéssaire de changer le méta-package lui même pour corriger des problèmes. Quand cette situation survient nous changeons sa version pour pouvoir la différencier de celle qui a des problèmes même si les niveaux des composants n’ont pas changé. Les anciens niveaux ne sont pas supprimés de pypi, il suffit de recharger la nouvelle version.

Incrément des version Mineures

En plus du cas ou un élément est ajouté au méta-package, son niveau de version mineure doit être incrémenté lorsque que l’un de ses composants a une augmentation de version mineure.

Par exemple supposons que le meta-package suit les 2 éléments qiskit-terra==0.7.0 et qiskit-aer==0.1.1, et que sa version courante est 0.7.5. Lorsque la version de qiskit-aer passe à 0.2.0 alors la version du méta-package va devoir passer à 0.8.0.

Incrément des version majeures

La version majeure est gérée de manière un peu différente des autres composantes constituant la gestion des version, lesquelles sont modifiées selon les changement de version des composants. La version majeure n’est changée que lors d’un changement de version de tous les composants (du moins avant la version 1.0.0). Actuellement tous les composants on un niveau de majeur 0``et tant qu'ils ne seront pas tous marqués comme ayant atteint une version stable (donc a une version majeure ``>=1) alors le méta-package ne peut pas passer à la version majeure suivante.

La règle de changement de version majeure du meta-package après que tous les composants soient à une version >=1.0.0 n’est pas encore déterminée.

Elements de Qiskit nécessitant d’être suivis

Bien que ce ne soit pas strictement relié à la gestion des versions du méta-package et de Qiskit, la manière dont nous suivons les version des éléments dans les exigences du méta-package est importante. Chacun des éléments listés dans setup.py devrait correspondre à une version unique. Ceci signifie que chaque version de Qiskit ne définit qu’une seule version de chacun de ses éléments. Par exemple, la liste des exigences devrait toujours être de la forme :

requirements = [
    "qiskit_terra==0.7.0",
    "qiskit-aer==0.1.1",
]

Ceci est conçu de manière à aider au déboggage, mais aussi pour faciliter le suivi des versions pour l’ensemble des éléments.

Il peut également être intéressant de noter que l’ordre dans lequel les différents éléments sont installés est très important. ``pip``ne fait pas réellement de résolution de dépendance entre les éléments, nous devons donc veiller à ce que l’ordre des exigences soit correctement établi lorsqu’il le faut. Par exemple si il y a des exigences redondantes entre les éléments ou bien des dépendances entre les éléments.

Extensions de la communauté

Qiskit a été conçu en pensant à sa modularité. Il est extensible de plusieurs manières différentes, sur cette page nous montrons comment la communauté Qiskit a contribué en développant des extensions et packages additionnels.

Providers (fournisseurs de service)

Le provider de base de Qiskit The Qiskit permet d’accéder à un groupe de différentes plateformes d’exécution (par exemple les plateformes disponibles au travers de IBM Quantum). Il interagit avec ces plateformes de plusieurs manières : identifier quelles sont celles qui sont disponibles, obtenir des informations sur leurs propriétés et leur configuration, et pour prendre en charge l’execution des jobs.

Providers additionnels

  • Decision diagram-based quantum simulator

    Organisation: Johannes Kepler University, Linz, Austria (Alwin Zulehner et Robert Wille)
    Description: Un provider local qui permet à Qiskit d’effectuer des simulations quantiques basées sur des diagrammes de décision
    - Qiskit Version: 0.7
  • Quantum Inspire

    - Organization: QuTech-Delft
    - Description: A provider for the Quantum Inspire backend
    - Qiskit Version: 0.7
    Informations additionnelles : Medium Blog et dépôt Github.

Transpileur

L’optimisation des circuits est au coeur même de la possibilité de rendre le calcul quantique faisable sur du vrai matériel.

Passes additionnelles

  • t|ket〉optimization & routing pass

    - Organization: Cambridge Quantum Computing
    Description: Passe de transpilation pour l’optimisation des circuit et la correspondance à la plateforme d’exécution utilisant le compilateur t|ket〉de CQC.
    - Qiskit Version: 0.7
    Informations additionnelles : Tutorial Notebook et dépôt Github.

Outils

L’extension de Qiskit avec de nouveaux outils et fonctionnalités est une pièce majeure dans la construction d’une communauté. Ces outils peuvent être de nouvelles méthodes de visualisation, une intégration avec slack, des extensions de Juypter et bien d’autres choses.

Outils additionnels

  • Bibliothèque OpenControls

    - Organization: Q-CTRL
    Description : Bibliothèque d’impulsions micro-onde de contrôle quantique issues de la littérature libre.
    - Qiskit Version: 0.7
    - More info: GitHub and Q-CTRL website