Qiskit SDK estratégia de versão
Os números de versão do Qiskit seguem o Semantic Versioning.
O número da versão é composto por três componentes principais: as versões principal, secundária e versões de patch. Por exemplo, no número de versão X.Y.Z, X é a versão principal, Y é a versão secundária e Z é a versão de correção.
Alterações na API que causam incompatibilidade retroativa são reservadas para lançamentos de versões principais. O período mínimo entre o lançamento de versões principais é de um ano. As versões secundárias introduzem novos recursos e correções de bugs sem comprometer a compatibilidade da API e são publicadas periodicamente (atualmente, a cada três meses, aproximadamente) apenas para a versão principal atual. As versões de patch fornecem correções para bugs identificados na versão secundária mais recente de cada série de lançamentos com suporte ativo (ou seja, a versão principal). Oferecemos suporte a, no máximo, duas séries de lançamento ao mesmo tempo, o que ocorre apenas durante o período de sobreposição após o lançamento de uma nova versão principal, conforme descrito com mais detalhes a seguir.
Cronograma de lançamento
Exemplo de um ciclo de lançamento X para versões principais:
Para obter uma programação de lançamento atualizada, consulte a lista de marcos do projeto Qiskit GitHub, que sempre conterá o plano de lançamento atual.
Com o lançamento de uma nova versão principal, a versão principal anterior recebe suporte por pelo menos seis meses, apenas com correções de bugs, e um ano para correções de segurança. Durante durante esse período, são publicados apenas lançamentos de patches para essa versão principal. Uma versão final do patch é publicada quando o suporte é encerrado, e esse lançamento também documenta o fim do suporte para essa série de versões principais. Uma janela de suporte para a versão principal anterior, pois isso dá aos consumidores do Consumidores do Qiskit e seus usuários tenham a chance de migrar seus códigos. As bibliotecas downstream que dependem do Qiskit não devem aumentar a versão mínima exigida do Qiskit para uma nova versão principal imediatamente após seu lançamento, pois a base de usuários da biblioteca precisa de tempo para migrar para as novas alterações da API. Ter uma janela de suporte estendida para a versão principal anterior do Qiskit dá aos projetos posteriores tempo para garantir compatibilidade com a próxima versão principal. Os projetos downstream podem fornecer suporte para duas séries de versões ao mesmo tempo para oferecer aos seus usuários um caminho de migração.
Para fins de controle de versão semântico, a API pública do Qiskit é considerada qualquer módulo, classe, função ou método documentado que não esteja marcado como privado (com um prefixo de sublinhado _ ). No entanto, podem ser feitas exceções explícitas para aPIs documentadas específicas. Nesses casos, essas APIs serão claramente documentadas como ainda não sendo consideradas interfaces estáveis, e um aviso visível ao usuário será emitido ativamente em qualquer uso dessas interfaces instáveis. Além disso, em algumas situações, uma interface marcada como privada é considerada parte da API pública API. Normalmente, isso só ocorre em dois casos: ou uma definição de interface abstrata em que as subclasses devem substituir/implementar um método privado como parte da definição de uma implementação da interface, ou métodos de baixo nível de uso avançado métodos de baixo nível que têm interfaces estáveis, mas não são considerados seguros para uso, já que o ônus de manter as invariantes de classe/segurança recai sobre o próprio usuário (o exemplo canônico disso é o método QuantumCircuit._append ).
As versões suportadas do Python, a versão mínima suportada do Rust (para criar o Qiskit a partir da fonte) e quaisquer dependências do pacote Python (incluindo as versões mínimas (incluindo as versões mínimas suportadas das dependências) usadas pelo Qiskit não fazem parte das e podem mudar durante qualquer lançamento. Somente os lançamentos de versões menores ou maiores aumentarão os requisitos mínimos para uso ou criação do Qiskit (incluindo a adição de novas dependências), mas as correções de patches podem incluir suporte para novas versões do Python ou outras dependências. Normalmente, a versão mínima de uma dependência dependência só é aumentada quando as versões mais antigas da dependência deixam de ser suportadas ou quando não é possível manter a compatibilidade com a versão mais recente da dependência e a versão mais antiga.
Estratégia de upgrade
Quando uma nova versão principal é lançada, o caminho de atualização recomendado é fazer primeiro o upgrade para a versão secundária mais recente da versão principal anterior anterior. Pouco antes de uma nova versão principal, uma versão secundária final será final será publicada. Essa versão secundária final do lançamento X.Y+1.0.0 é equivalente a X.Y.0 mas com avisos e depreciações para quaisquer alterações de API que sejam feitas na nova série de versões principais.
Por exemplo, logo após o lançamento do 1.0.0, é publicado um lançamento do 0.46.0. A versão 0.46.0 é equivalente à versão 0.45.0, mas com avisos adicionais de descontinuação que documentam as alterações na API realizadas como parte da versão 1.0.0. Esse padrão se aplica a qualquer lançamento de versão principal.
Os usuários do Qiskit devem primeiro atualizar para esta versão final para ver quaisquer avisos de depreciação e ajustar o uso do Qiskit antes de tentar uma versão potencialmente disruptiva. A versão principal versão principal anterior terá suporte por pelo menos seis meses para dar tempo suficiente para fazer o upgrade. Um padrão típico para gerenciar isso é fixar a versão máxima para evitar usar a próxima série de versões principais até ter certeza da compatibilidade.
Por exemplo, especificar qiskit<2 em um arquivo de requisitos quando a versão principal atual do versão principal atual do Qiskit é 1 garante que você esteja usando uma versão do Qiskit que não tenha alterações significativas na API.
Limitar a versão a menos do que a próxima versão principal garante que você veja todos os avisos de depreciação antes do lançamento de uma lançamento da versão principal.
Sem o limite, o pip instala a versão mais recente disponível por padrão.
O formato de serialização QPY é compatível com versões anteriores, de modo que uma nova versão do Qiskit sempre pode carregar um arquivo QPY gerado com uma versão anterior do Qiskit. No entanto, o formato não é compatível com o futuro, portanto, em princípio, não é possível carregar arquivos QPY gerados com uma versão mais recente do Qiskit usando uma versão mais antiga. Para facilitar a migração do usuário entre os principais lançamentos de versões, a função qiskit.qpy.dump() sempre oferecerá suporte a pelo menos uma versão sobreposta entre a versão X.0.0 e a X-1.Y.0 (em que Y é a última versão secundária da dessa série). O parâmetro qiskit.qpy.dump(..., version=...) permitirá salvar arquivos no formato QPY que podem ser carregados por ambas as versões principais da versão mais recente versão mais recente. Veja mais detalhes na RFC 0020.
Pré-lançamentos
Para cada lançamento de versão secundária e principal, o Qiskit publica pré-lançamentos que são compatíveis com PEP440. Normalmente esses são candidatos a lançamento no formato X.Y.0rc1. As versões rc terão uma superfície de API finalizada e são usadas para testar uma versão futura.
Observe que, quando um dos sufixos de pré-lançamento PEP440 (como a, b, ou pre) é
publicado, ele não oferece as mesmas garantias que um lançamento rc , sendo
apenas uma versão de pré-visualização. A API pode sofrer alterações entre essas versões preliminares
e a versão final com esse número de versão. Por exemplo, X.0.0pre1 pode ter
uma API diferente da versão final X.0.0.
Pós-lançamentos
Se houver problemas com a embalagem de um lançamento, poderá ser emitido um pós-lançamento para para corrigir esse problema. Eles seguirão o formato X.Y.Z.1 , em que o quarto indica que é a primeira versão pós-lançamento da versão X.Y.Z .
Por exemplo, a versão qiskit-terra (o nome do pacote legado para o Qiskit) 0.25.2 teve algum problema com a publicação do pacote sdist, e foi publicado um pós-lançamento 0.25.2.1 que corrigiu esse problema. O código era idêntico e 0.25.2.1 apenas corrigiu o problema de empacotamento da versão.
Como os colaboradores podem marcar depreciações
Consulte o guia de depreciação no repositório Qiskit SDK para obter instruções sobre como adicionar depreciações ao código-fonte.