Qiskit SDK strategia di versione
I numeri di versione di Qiskit seguono il Semantic Versioning.
Il numero di versione è composto da tre componenti principali: la versione maggiore, la versione minore e la versione versione patch. Ad esempio, nel numero di versione X.Y.Z, X è la versione principale, Y è la versione minore e Z è la versione della patch.
Le modifiche alle API che comportano l'incompatibilità con le versioni precedenti sono riservate alle versioni principali. Il periodo minimo tra il rilascio di due versioni principali è di un anno. Le versioni minori introducono nuove funzionalità e correzioni di bug senza compromettere la compatibilità delle API e vengono pubblicate periodicamente (attualmente, circa ogni tre mesi) solo per la versione principale corrente. Le versioni patch forniscono correzioni per i bug individuati nella versione minore più recente di ciascuna serie di release attivamente supportata (ovvero la versione maggiore). Supportiamo al massimo due serie di release alla volta, il che avviene solo durante il periodo di sovrapposizione successivo al rilascio di una nuova versione principale, come descritto più dettagliatamente di seguito.
Calendario delle uscite
Esempio di cadenza delle versioni principali X:
Per un programma di rilascio aggiornato, fate riferimento all' elenco delle milestone del progetto Qiskit GitHub, che conterrà sempre il piano di rilascio attuale.
Con il rilascio di una nuova versione principale, la versione principale precedente è supportata per almeno sei mesi con le sole correzioni di bug e per un anno per le correzioni di sicurezza. Durante questo durante questo periodo vengono pubblicati solo rilasci di patch per questa versione principale. Una versione finale della patch viene pubblicata quando il supporto viene interrotto e tale rilascio documenta anche la fine del supporto per quella serie di versioni principali documenta anche la fine del supporto per quella serie di versioni principali. Una finestra di supporto più lunga è necessaria una finestra di supporto più lunga per la versione principale precedente, in modo da dare ai consumatori di Qiskit a valle e ai loro utenti la possibilità di migrare il loro codice Qiskit e ai loro utenti la possibilità di migrare il loro codice. Le librerie a valle che le librerie downstream che dipendono da Qiskit non dovrebbero aumentare la loro versione minima richiesta di Qiskit a una nuova versione principale subito dopo il suo rilascio, perché la base di utenti della libreria ha bisogno di tempo per tempo per migrare alle nuove modifiche dell'API. La presenza di una finestra di supporto estesa per la precedente versione principale di Qiskit dà ai progetti a valle il tempo di garantire la compatibilità con la versione successiva compatibilità con la versione principale successiva. I progetti a valle possono fornire il supporto per due serie di release alla volta per offrire ai propri utenti un percorso di migrazione.
Ai fini del versioning semantico, l'API pubblica di Qiskit è considerata come qualsiasi modulo, classe, funzione o metodo documentato che non sia contrassegnato come privato (con il prefisso underscore ) (con il prefisso underscore _ ). Tuttavia, possono essere previste eccezioni esplicite per specifiche API documentate. In questi casi, queste API saranno chiaramente documentate come non non sono ancora considerate interfacce stabili e un avvertimento visibile all'utente verrà un avviso visibile all'utente su qualsiasi uso di queste interfacce instabili. Inoltre, in alcune situazioni, un'interfaccia contrassegnata come privata è considerata parte dell'API pubblica API. In genere questo avviene solo in due casi: o una definizione di interfaccia astratta dove le sottoclassi sono destinate a sovrascrivere/implementare un metodo privato come parte della definizione di un'implementazione dell'interfaccia, o metodi di basso livello ad uso avanzato metodi di basso livello che hanno interfacce stabili ma non sono considerati sicuri da usare, poiché l'onere di rispettare gli invarianti di classe/sicurezza è a carico dell'utente stesso (l'esempio canonico è il metodo QuantumCircuit._append ).
Le versioni supportate di Python, la versione minima supportata di Rust (per la compilazione di Qiskit dai sorgenti) e tutte le dipendenze del pacchetto Python (comprese le versioni minime supportate delle dipendenze) utilizzate da Qiskit non fanno parte del pacchetto retrocompatibile supportate) utilizzate da Qiskit non fanno parte delle garanzie di retrocompatibilità e possono cambiare durante qualsiasi release compatibilità all'indietro e possono cambiare durante qualsiasi rilascio. Solo le versioni minori o maggiori aumenteranno i requisiti minimi per l'utilizzo o la creazione di Qiskit (inclusa l'aggiunta di nuove dipendenze) (compresa l'aggiunta di nuove dipendenze), ma le correzioni delle patch potrebbero includere il supporto per nuove versioni di Python o altre dipendenze. Di solito la versione minima di una di una dipendenza viene aumentata solo quando le versioni più vecchie della dipendenza non sono più supportate o quando non è possibile mantenere la compatibilità tra l'ultima versione della dipendenza e la versione precedente dipendenza e la versione più vecchia.
Strategia di aggiornamento
Quando viene rilasciata una nuova versione principale, il percorso di aggiornamento raccomandato è quello di passare prima alla versione minore più recente sulla versione maggiore precedente precedente. Poco prima di una nuova versione principale, verrà pubblicata una versione finale minore. Questa versione minore finale X.Y+1.0.0 è equivalente a X.Y.0 ma con avvertenze e deprecazioni per le modifiche alle API che vengono apportate nella nuova serie di versioni maggiori.
Ad esempio, subito dopo la pubblicazione dell’articolo “ 1.0.0 ”, viene pubblicato l’articolo “ 0.46.0 ”. La versione 0.46.0 è equivalente alla versione 0.45.0, ma include ulteriori avvisi di deprecazione che documentano le modifiche all'API apportate nell'ambito della versione 1.0.0. Questo modello si applica a tutte le principali versioni.
Gli utenti di Qiskit dovrebbero prima aggiornare a questa versione finale minore per vedere tutti gli avvisi di deprezzamento e regolare l'uso di Qiskit prima di provare una versione prima di provare una versione potenzialmente dirompente. La versione precedente la versione principale precedente sarà supportata per almeno sei mesi, in modo da avere il tempo sufficiente per per effettuare l'aggiornamento. Uno schema tipico per gestire questo problema è quello di bloccare la versione massima per evitare di usare la successiva serie di release principali finché non si è sicuri della compatibilità.
Ad esempio, specificando qiskit<2 in un file di requisiti quando la versione principale di Qiskit è la 1, ci si assicura di utilizzare una versione di Qiskit che non sia la più diffusa versione principale di Qiskit è la 1 assicura che si stia utilizzando una versione di Qiskit che non presenta modifiche radicali all'API.
Limitare la versione a meno della versione principale successiva assicura che si vedano gli avvisi di deprezzamento prima del rilascio di una versione versione principale.
Senza il limite, pip installa la versione più recente disponibile per impostazione predefinita.
Il formato di serializzazione QPY è retrocompatibile, in modo che una nuova versione di Qiskit possa sempre caricare un file QPY generato con una versione precedente di Qiskit generato con una versione precedente di Qiskit. Tuttavia, il formato non è compatibile con il futuro e quindi, in linea di massima, non è possibile caricare i file QPY generati con una versione più recente di Qiskit utilizzando una versione precedente. Per facilitare la migrazione degli utenti tra le versioni principali, la funzione qiskit.qpy.dump() supporta sempre almeno una versione sovrapposta tra la release X.0.0 e la release X-1.Y.0 (dove Y è l'ultima versione minore di quella serie) quella serie). Il parametro qiskit.qpy.dump(..., version=...) consente di salvare i file in formato QPY che possono essere caricati da entrambe le versioni principali dalla release più recente versione più recente. Per maggiori dettagli, consultare la RFC 0020.
Pre-rilasci
Per ogni versione minore e maggiore, Qiskit pubblica delle pre-release che sono compatibili con PEP440. Tipicamente si tratta di candidati al rilascio della forma X.Y.0rc1. I rilasci rc avranno una superficie API finalizzata e sono usate per testare una release futura.
Si noti che quando viene pubblicato uno dei suffissi delle versioni preliminari di PEP440 (come a, b, o pre),
tale versione non offre le stesse garanzie di una rc versione definitiva ed è
solo una versione di anteprima. L'API potrebbe subire modifiche tra queste versioni preliminari
e la versione definitiva con quel numero di versione. Ad esempio, X.0.0pre1 potrebbe avere
un'API diversa rispetto alla versione finale X.0.0.
Post-rilasci
Se ci sono problemi con la confezione di una release, potrebbe essere emessa una post-release per correggerli per correggere il problema. Questi seguiranno la forma X.Y.Z.1 , dove il quarto numero intero indica che si tratta del primo rilascio successivo a indica che si tratta della prima release successiva alla release X.Y.Z .
Per esempio, il rilascio di qiskit-terra (il nome del pacchetto legacy per Qiskit) 0.25.2 aveva qualche problema con la pubblicazione del pacchetto sdist, ed è stata pubblicata una post-release che ha corretto il problema 0.25.2.1 che ha corretto il problema. Il codice era identico e 0.25.2.1 e ha risolto solo il problema dell'impacchettamento per il rilascio.
Come i contributori possono contrassegnare le deprecazioni
Fare riferimento alla guida alle deprecazioni nel repository Qiskit SDK per le istruzioni su come aggiungere le deprecazioni al codice sorgente.