Qiskit SDK stratégie de version
Les numéros de version de Qiskit suivent le principe du Semantic Versioning.
Le numéro de version se compose de trois éléments principaux : la version majeure, la version mineure et la version du correctif la version du correctif. Par exemple, dans le numéro de version X.Y.Z, X est la version majeure, Y est la version mineure, et Z est la version corrective.
Les modifications de l'API ayant un impact sur la compatibilité ascendante sont réservées aux mises à jour majeures. Le délai minimum entre deux versions majeures est d'un an. Les versions mineures apportent de nouvelles fonctionnalités et des corrections de bogues sans rompre la compatibilité de l'API, et sont publiées périodiquement (actuellement, environ tous les trois mois) uniquement pour la version majeure en cours. Les versions de correctifs apportent des corrections aux bogues identifiés dans la version mineure la plus récente de chaque série de versions activement prise en charge (c'est-à-dire la version majeure). Nous prenons en charge au maximum deux séries de versions à la fois, ce qui ne se produit que pendant la période de chevauchement suivant la sortie d'une nouvelle version majeure, comme décrit plus en détail ci-dessous.
Calendrier de sortie
Exemple de cadence de publication des versions majeures X :
Pour obtenir un calendrier de mise à jour, consultez la liste des étapes du projet Qiskit GitHub, qui contiendra toujours le plan de mise à jour.
Lors de la sortie d'une nouvelle version majeure, la version majeure précédente est prise en charge pendant au moins six mois pour les corrections de bogues et un an pour les corrections de sécurité. Pendant cette période, seuls des correctifs sont publiés pour cette version majeure pendant cette période, seuls des correctifs sont publiés pour cette version majeure. Une version finale du correctif est publiée lorsque le support est abandonné, et cette version documente également la fin du support pour cette série de versions majeures. Une fenêtre de soutien plus longue est nécessaire pour la version majeure précédente est nécessaire pour la version majeure précédente afin de donner aux consommateurs de Qiskit en aval et à leurs utilisateurs la possibilité de migrer leur code Qiskit en aval et à leurs utilisateurs de migrer leur code. Les bibliothèques en aval qui dépendent de Qiskit ne devraient pas augmenter leur version minimale requise de Qiskit à une nouvelle version majeure immédiatement après sa sortie parce que la base d'utilisateurs de la bibliothèque a besoin de temps pour s'adapter version majeure immédiatement après sa sortie, car la base d'utilisateurs de la bibliothèque a besoin de temps pour migrer vers les nouveaux changements de l'API de migrer vers les nouvelles modifications de l'API. Le fait de disposer d'une fenêtre d'assistance étendue pour la version majeure précédente de Qiskit donne aux projets en aval le temps d'assurer la compatibilité avec la version majeure suivante la compatibilité avec la version majeure suivante. Les projets en aval peuvent prendre en charge deux séries de versions à la fois afin d'offrir à leurs utilisateurs un chemin de migration la prise en charge de deux séries de versions à la fois afin d'offrir à leurs utilisateurs un chemin de migration.
Pour les besoins de la version sémantique, l'API publique de Qiskit est considérée comme tout module, classe, fonction ou méthode documenté qui n'est pas marqué comme privé (avec un préfixe de soulignement _ ). Toutefois, il peut y avoir des exceptions explicites pour des API spécifiques documentées. Dans ce cas, ces API seront clairement documentées comme n'étant pas encore considérées comme des interfaces stables pas encore considérées comme des interfaces stables, et un avertissement visible par l'utilisateur sera visible par l'utilisateur sera activement émis lors de toute utilisation de ces interfaces instables. En outre, dans certaines situations, une interface marquée comme privée est considérée comme faisant partie de l'API publique API. En général, cela ne se produit que dans deux cas : soit une interface abstraite abstraite où les sous-classes sont censées surcharger/implémenter une méthode privée dans le cadre de la définition d'une implémentation de l'interface, soit une utilisation avancée de la méthode dans le cadre de la définition d'une implémentation de l'interface, ou des méthodes de bas niveau à usage avancé qui ont des interfaces stables mais qui ne sont pas considérées comme sûres les méthodes de bas niveau qui ont des interfaces stables mais dont l'utilisation n'est pas considérée comme sûre, étant donné qu'il incombe à l'utilisateur de respecter lui-même les invariants de classe/sécurité (l'exemple canonique est la méthode QuantumCircuit._append ).
Les versions supportées de Python, la version minimale supportée de Rust (pour la construction de Qiskit à partir des sources), et toutes les dépendances du paquet Python (y compris les versions minimales minimum supportées) utilisées par Qiskit ne font pas partie des garanties de rétrocompatibilité et peuvent changer au cours d'une version. Seules les versions mineures ou majeures augmenteront les exigences minimales pour l'utilisation ou la construction de Qiskit (y compris l'ajout de nouvelles dépendances), mais les correctifs peuvent inclure la prise en charge de nouvelles versions de Python ou d'autres dépendances. Habituellement, la version minimale d'une d'une dépendance n'est augmentée que lorsque les anciennes versions de la dépendance ne sont plus prises en charge ou lorsqu'il n'est pas possible de maintenir la compatibilité avec la dernière version de la dépendance lorsqu'il n'est pas possible de maintenir la compatibilité entre la dernière version de la et l'ancienne version.
Stratégie de mise à niveau
Lorsqu'une nouvelle version majeure est publiée, la procédure de mise à niveau recommandée consiste à passer d'abord à la version mineure la plus récente sur la version majeure précédente est de passer d'abord à la version mineure la plus récente de la version majeure précédente précédente. Peu avant la publication d'une nouvelle version majeure, une version mineure finale sera publiée sera publiée. Cette version mineure finale X.Y+1.0.0 est équivalente à X.Y.0 mais avec des avertissements et des dépréciations pour tous les changements d'API qui sont apportées à la nouvelle série de versions majeures.
Par exemple, juste après la publication de l'article « 1.0.0 », un article intitulé « 0.46.0 » est publié. La version « 0.46.0 » est équivalente à la version « 0.45.0 », mais comporte des avertissements supplémentaires concernant les fonctionnalités obsolètes, qui documentent les modifications apportées à l'API dans le cadre de la version « 1.0.0 ». Ce modèle s'applique à toutes les versions majeures.
Les utilisateurs de Qiskit devraient d'abord mettre à jour cette version mineure finale pour voir les éventuels avertissements de dépréciation et ajuster leur système Qiskit pour voir les avertissements de dépréciation et ajuster leur utilisation de Qiskit avant d'essayer une version potentiellement révolutionnaire. La version majeure la version majeure précédente sera prise en charge pendant au moins six mois afin de laisser suffisamment de temps pour la mise à jour pour la mise à jour. Un modèle typique pour gérer cela est d'épingler la version maximale afin d'éviter d'utiliser la prochaine série de versions majeures avant d'être sûr de la compatibilité d'éviter d'utiliser la série de versions majeures suivante jusqu'à ce que vous soyez sûr de la compatibilité.
Par exemple, le fait de spécifier qiskit<2 dans un fichier d'exigences lorsque la version majeure de Qiskit est 1 garantit l'utilisation d'une version de Qiskit plus récente majeure de Qiskit est 1 garantit que vous utilisez une version de Qiskit qui n'a pas subi de modifications majeures de l'API.
Le fait de plafonner la version à un niveau inférieur à la prochaine version majeure permet de s'assurer que les avertissements de dépréciation sont visibles avant la sortie d'une version majeure.
Sans le capuchon, pip installe la dernière version disponible par défaut.
Le format de sérialisation QPY est rétrocompatible, de sorte qu'une nouvelle version de Qiskit peut toujours charger un fichier QPY généré avec une version antérieure de Qiskit. Cependant, le format n'est pas compatible avec les versions ultérieures, de sorte qu'en principe, il n'est pas possible de charger des fichiers QPY générés avec une version plus récente de Qiskit en utilisant une version antérieure de charger des fichiers QPY générés avec une version plus récente de Qiskit en utilisant une version plus ancienne. Pour faciliter la migration des utilisateurs entre les versions majeures, la fonction qiskit.qpy.dump() prendra toujours en charge au moins une version qui se chevauche entre la version X.0.0 et la version X-1.Y.0 (où Y est la dernière version mineure de la série) cette série). Le paramètre qiskit.qpy.dump(..., version=...) permet d'enregistrer des fichiers au format QPY qui peuvent être chargés par les deux versions majeures à partir de la version la plus récente plus récente. Voir plus de détails dans le RFC 0020.
Pré-sorties
Pour chaque version mineure et majeure, Qiskit publie des pré-versions qui sont compatibles avec PEP440. En règle générale il s'agit de candidats à la publication de la forme X.Y.0rc1. Les versions rc auront une surface d'API finalisée et sont utilisées pour tester une version future.
Notez que lorsqu'un des suffixes de préversion d' PEP440 (tels que a, b, ou pre) est
publié, il ne bénéficie pas des mêmes garanties qu'une rc version et ne constitue
qu'une version préliminaire. L'API est susceptible d'évoluer entre ces versions préliminaires
et la version finale portant ce numéro de version. Par exemple, X.0.0pre1 pourrait avoir
une API différente de celle de la version finale X.0.0.
Post-communiqués
Si l'emballage d'une version pose problème, une post-sortie peut être publiée pour y remédier pour y remédier. Ils prendront la forme X.Y.Z.1 , où le quatrième entier indique qu'il s'agit de la première post-publication de la version indique qu'il s'agit de la première post-version de la version X.Y.Z .
Par exemple, la version qiskit-terra (l'ancien nom du paquet pour Qiskit) 0.25.2 avait un problème avec la publication du paquet sdist, et une post-version a été publiée pour corriger ce problème 0.25.2.1 a été publiée pour corriger ce problème. Le code était identique et 0.25.2.1 n'a corrigé que le problème de l'emballage de la version.
Comment les contributeurs peuvent signaler les dépréciations
Consultez le guide des dépréciations dans le dépôt Qiskit SDK pour savoir comment ajouter des dépréciations au code source.