Qiskit SDK estrategia de versiones
Los números de versión de Qiskit siguen el Versionado Semántico.
El número de versión consta de tres componentes principales: la versión mayor, la menor y el parche versiones de parche. Por ejemplo, en el número de versión X.Y.Z, X es la versión mayor, Y es la versión menor, y Z es la versión del parche.
Los cambios en la API que afectan a la compatibilidad se reservan para las versiones principales. El plazo mínimo entre el lanzamiento de una versión principal y la siguiente es de un año. Las versiones menores introducen nuevas funciones y correcciones de errores sin alterar la compatibilidad de la API, y se publican periódicamente (actualmente, aproximadamente cada tres meses) únicamente para la versión principal actual. Las versiones de parche proporcionan correcciones para los errores detectados en la versión menor más reciente de cada serie de versiones con soporte activo (es decir, la versión principal). Admitimos un máximo de dos series de versiones a la vez, lo cual ocurre únicamente durante el periodo de solapamiento que sigue al lanzamiento de una nueva versión principal, tal y como se describe con más detalle a continuación.
Calendario de lanzamientos
Ejemplo de una cadencia de versiones principales X:
Para obtener un calendario de versiones actualizado, consulta la lista de hitos del proyecto Qiskit GitHub, que siempre contendrá el plan de versiones actual.
Con el lanzamiento de una nueva versión principal, la versión principal anterior recibe soporte durante al menos seis meses sólo con correcciones de errores, y un año para correcciones de seguridad. Durante sólo se publican parches para esta versión principal. Se publica una versión final del parche cuando se deja de dar soporte, y esa versión también documenta el fin del soporte para esa serie de versiones principales. Se necesita para la versión principal anterior, ya que esto da a los consumidores de Qiskit y a sus usuarios la oportunidad de migrar su código Qiskit y a sus usuarios la oportunidad de migrar su código. Las bibliotecas downstream que dependen de Qiskit no deben aumentar su versión mínima requerida de Qiskit a una nueva versión principal inmediatamente después de su lanzamiento porque la base de usuarios de la biblioteca necesita tiempo para migrar a los nuevos cambios de la API para migrar a los nuevos cambios de la API. Contar con una ventana de soporte ampliada para la versión principal anterior de Qiskit da tiempo a los proyectos posteriores para garantizar la compatibilidad con la siguiente versión principal compatibilidad con la siguiente versión principal. Los proyectos posteriores pueden ofrecer compatibilidad con dos series de versiones a la vez para ofrecer a sus usuarios una ruta de migración.
A efectos del versionado semántico, se considera API pública de Qiskit cualquier módulo, clase, función o método documentado que no esté marcado como privado (con un prefijo de guión bajo _ ). Sin embargo, puede haber excepciones explícitas para aPI específicas documentadas. En tales casos, estas API estarán claramente documentadas que aún no se consideran interfaces estables, y se emitirá una advertencia visible para el usuario se emitirá activamente sobre cualquier uso de estas interfaces inestables. Además, en algunas situaciones, una interfaz marcada como privada se considera parte de la API pública PÚBLICA. Por lo general, esto sólo ocurre en dos casos: o bien una interfaz abstracta abstracta en la que las subclases deben anular/implementar un método privado como parte de la definición de una implementación de la interfaz, o métodos de bajo nivel de uso avanzado métodos de bajo nivel que tienen interfaces estables pero cuyo uso no se considera seguro, ya que es el usuario quien debe mantener las invariantes de clase/seguridad (el ejemplo canónico es el método QuantumCircuit._append ).
Las versiones de Python soportadas, la versión mínima de Rust soportada (para construir Qiskit desde el código fuente), y cualquier dependencia de los paquetes Python (incluidas las versiones mínimas versiones mínimas soportadas de las dependencias) usadas por Qiskit no son parte de las garantías de compatibilidad y pueden cambiar durante cualquier versión. Sólo las versiones menores o mayores aumentarán los requisitos mínimos para utilizar o compilar Qiskit (incluyendo la adición de nuevas dependencias), pero las correcciones de parches pueden incluir soporte para nuevas versiones de Python u otras dependencias. Normalmente, la versión mínima de una dependencia sólo se aumenta cuando las versiones anteriores de la dependencia dejan de ser compatibles o cuando no es posible mantener la compatibilidad entre la última versión de la y la versión anterior.
Estrategia de actualización
Cuando se publica una nueva versión principal, la ruta de actualización recomendada a la versión menor más reciente de la versión mayor anterior anterior. Poco antes de una nueva versión principal, se publicará una versión final menor final. Esta versión final menor X.Y+1.0.0 es equivalente a X.Y.0 pero con advertencias y deprecaciones para cualquier cambio en la API que se realizados en la nueva serie de versiones mayores.
Por ejemplo, justo después del lanzamiento de « 1.0.0 », se publica el de « 0.46.0 ». La versión 0.46.0 es equivalente a la versión 0.45.0, pero incluye advertencias adicionales sobre funciones obsoletas que documentan los cambios en la API realizados como parte de la versión 1.0.0. Este patrón se aplica a cualquier lanzamiento de una versión principal.
Los usuarios de Qiskit deben actualizar primero a esta versión final menor versión para ver las advertencias de obsoleto y ajustar su Qiskit antes de probar una versión potencialmente disruptiva. La versión se mantendrá durante al menos seis meses para dar tiempo suficiente a la actualización para actualizar. Un patrón típico para gestionar esto es fijar la versión máxima para evitar el uso de la siguiente serie de versiones principales hasta estar seguro de la compatibilidad.
Por ejemplo, especificar qiskit<2 en un archivo de requisitos cuando la versión versión principal de Qiskit es 1 asegura que estás usando una versión de Qiskit que no tiene cambios importantes en la API.
La limitación a una versión inferior a la siguiente versión principal se asegura de que usted vea cualquier advertencia de obsoleto antes de una versión mayor.
Sin la tapa, pip instala la versión más reciente disponible por defecto.
El formato de serialización QPY es compatible con versiones anteriores, de modo que una nueva versión de Qiskit siempre puede cargar un archivo QPY generado con una versión anterior de Qiskit. Sin embargo, el formato no es compatible con versiones anteriores, por lo que, en principio, no es posible cargar archivos QPY generados con una versión más reciente de Qiskit utilizando una versión anterior. Para facilitar la migración de los usuarios entre versiones mayores, la función qiskit.qpy.dump() función siempre admitirá al menos una versión solapada entre la versión X.0.0 y la versión X-1.Y.0 (donde Y es la última versión menor de esa serie). El parámetro qiskit.qpy.dump(..., version=...) permitirá guardar archivos en formato QPY que pueden ser cargados por las dos versiones principales de la nueva más recientes. Consulte más detalles en RFC 0020.
Preestrenos
Para cada versión menor y mayor, Qiskit publica versiones preliminares que son compatibles con PEP440. Normalmente se trata de versiones candidatas de la forma X.Y.0rc1. Las versiones rc tendrán una superficie de API finalizada y se utilizan para probar una futura versión.
Ten en cuenta que cuando se publica uno de los sufijos de versión preliminar de PEP440 (como a, b, o pre),
este no ofrece las mismas garantías que una rc versión y es
solo una versión de vista previa. La API podría sufrir cambios entre estas versiones preliminares
y la versión definitiva con ese número de versión. Por ejemplo, X.0.0pre1 podría tener
una API diferente a la de la versión final X.0.0.
Publicaciones posteriores
Si hay problemas con el embalaje de una edición, puede que se publique un para corregirlo. Estos seguirán la forma X.Y.Z.1 donde el cuarto indica que se trata de la primera versión posterior a la de X.Y.Z .
Por ejemplo, la versión qiskit-terra (el nombre del paquete heredado de Qiskit) 0.25.2 tenía algún problema con la publicación del paquete sdist, y se publicó un post-lanzamiento 0.25.2.1 que corregía este problema. El código era idéntico, y 0.25.2.1 sólo se arregló el problema de empaquetado de la versión.
Cómo pueden los colaboradores marcar las obsolescencias
Consulte la guía de de preciaciones en el repositorio Qiskit SDK para obtener instrucciones sobre cómo añadir depreciaciones al código fuente.