Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Política de retención de versiones de Nextflow
Versiones del motor Nextflow compatibles
HealthOmics admite varias versiones estables del motor Nextflow. Cada versión admite una o más versiones de idiomas específicos de dominio (DSL). En la siguiente tabla se muestran las versiones compatibles actualmente.
| Versión | Soporte DSL | HealthOmics fecha de lanzamiento | Status |
|---|---|---|---|
| v2.04 | DSL 1 y DSL 2 | noviembre de 2022 | Su obsolescencia está programada para el 30 de noviembre de 2026 |
| v23.10 | DSL 2 | Octubre de 2024 | Su obsolescencia está programada para el 30 de noviembre de 2027 |
| v24.10 | DSL 2 | Agosto de 2025 | Compatible al menos hasta noviembre de 2027 |
| v25.10 | DSL 2 | Abril de 2022 | Compatible al menos hasta octubre de 2028 |
| v26.04 | DSL 2 | Junio de 2026 | Última versión, compatible al menos hasta abril de 2029 |
HealthOmics no es compatible con las versiones «periféricas» mensuales. HealthOmics admite las funciones publicadas en cada versión, pero no las funciones de vista previa.
Una versión puede permanecer disponible para ejecutar flujos de trabajo una vez que deje de ser compatible. Las versiones compatibles (el año natural actual más los dos años anteriores) reciben nuevas funciones y mejoras de compatibilidad. Deprecated-but-available las versiones solo reciben parches de seguridad.
¿Cuánto tiempo permanecen disponibles las versiones del motor Nextflow?
HealthOmics admite las versiones de Nextflow publicadas en el año calendario actual, además de las versiones publicadas en los dos años anteriores. Solo estas versiones compatibles reciben lanzamientos de funciones y mejoras de compatibilidad con versiones anteriores. En la práctica:
-
En 2026: las familias de años compatibles son 26x, 25x y 24x.
-
En 2027: cuando se publique el 27.04, las familias de los años con soporte pasarán a ser 27.x, 26.x y 25.x.
Cuando la primera versión estable de un nuevo año natural esté disponible de forma generalizada HealthOmics, la familia del año más antiguo pasará a estar obsoleta.
Cuando una versión recibe un aviso de obsolescencia (entra en el periodo de preaviso del T-12 al T—0), el mantenimiento se limita únicamente a los parches de seguridad. No se añaden nuevas funciones a las versiones en desuso.
Ciclo de vida de desaprobación
Cuando una versión de Nextflow esté programada para quedar obsoleta HealthOmics, recibirás un aviso mínimo de 12 meses. A esto le siguen hasta 24 meses de disponibilidad extendida de la versión, en tres fases distintas.
| Fase | Plazo | Disponibilidad de versiones | Mantenimiento | Precios | Creación de flujos de trabajo | Iniciar una ejecución | Tu acción |
|---|---|---|---|---|---|---|---|
| Fase 1: Período de notificación | T-12 a T—0 | Totalmente funcional para los flujos de trabajo existentes a un precio estándar | Solo parches de seguridad | Tarifa estándar (sin cambios) | No está disponible en las versiones obsoletas | Totalmente funcional para los flujos de trabajo existentes | Migre para evitar los precios de disponibilidad extendida de versiones |
| Fase 2: Disponibilidad extendida de las versiones | De 0 a T, más de 24 meses | Totalmente funcional para los flujos de trabajo existentes a precios de disponibilidad de versiones ampliadas | Solo parches de seguridad | 2 veces (meses 0 a 12), 4 veces (meses 12 a 24 meses) | No está disponible en las versiones obsoletas | Totalmente funcional para los flujos de trabajo existentes, sujeto a los precios de disponibilidad de versiones ampliadas | Inicie nuevas ejecuciones con las versiones compatibles o actualice la versión predeterminada del flujo de trabajo para salir del precio de disponibilidad de la versión extendida |
| Fase 3: Fin del ciclo de vida | Después de T+24 meses | Retirado del servicio | Ninguno | N/A — las ejecuciones fallan | No está disponible en las versiones obsoletas | La ejecución falla en las versiones no compatibles (o retiradas) | Debe actualizarse para reanudar las ejecuciones o iniciar nuevas ejecuciones en las versiones compatibles |
Fase 1: Período de notificación (de T-12 a T—0)
Durante el período de preaviso:
-
Si utilizas la versión obsoleta, recibirás información sobre el cronograma y los flujos de trabajo afectados por correo electrónico, AWS Health Dashboard y anuncios en la consola.
-
La versión sigue siendo funcional para los flujos de trabajo existentes a un precio estándar.
-
No puede crear nuevos flujos de trabajo en versiones obsoletas, pero puede iniciar nuevas ejecuciones en los flujos de trabajo existentes a un precio estándar.
-
Solo se aplican los parches de seguridad. No se proporcionan nuevas funciones ni correcciones de errores para la versión obsoleta.
-
Le recomendamos que pruebe y migre a una versión compatible más reciente.
-
Recibirás recordatorios para migrar los flujos de trabajo que utilizan la versión obsoleta.
Fase 2: disponibilidad ampliada de la versión (de 0 a T más de 24 meses)
Tras la fecha de caducidad (T):
-
Las nuevas ejecuciones que se inicien con versiones en desuso están sujetas a un precio de disponibilidad de versiones ampliadas. Puedes evitar este precio iniciando nuevas ejecuciones en versiones compatibles o actualizando tu flujo de trabajo para usar una versión compatible.
-
No puedes crear nuevos flujos de trabajo en las versiones obsoletas.
-
Solo se aplican los parches de seguridad. No se proporcionan nuevas funciones ni correcciones de errores para la versión obsoleta.
-
Recibirás notificaciones sobre los precios de disponibilidad extendida de las versiones si tus flujos de trabajo siguen usando versiones obsoletas. Los precios de disponibilidad extendida de las versiones se aplican solo si durante esta fase se inician nuevas ejecuciones con versiones obsoletas.
-
Para iniciar una ejecución en las versiones compatibles, consulta cómo fijar la versión del motor Nextflow. Especifique la configuración del motor Nextflow
En la siguiente tabla se resumen los precios de disponibilidad de las versiones ampliadas.
| Periodo | Precios |
|---|---|
| T—0 a T+12 meses | El doble de la tarifa base para ejecuciones nuevas en versiones no compatibles |
| T+12 a T+24 meses | Tarifa base 4 veces mayor para ejecuciones nuevas en versiones no compatibles |
Fase 3: fin de la vida útil (después de más de 24 meses)
Una vez finalizado el período de disponibilidad de la versión ampliada:
-
Recibirás una notificación final sobre la retirada de la versión si algún flujo de trabajo sigue utilizando la versión retirada.
-
La versión se ha eliminado por completo del servicio. No puede crear nuevos flujos de trabajo ni iniciar nuevas ejecuciones en la versión retirada.
-
Las definiciones de flujo de trabajo existentes permanecen accesibles, pero no se ejecutan en la versión retirada.
-
Debes actualizar tu flujo de trabajo para usar una versión del motor compatible o fijar una versión compatible
StartRun. Para obtener más información sobre la fijación de versiones al iniciar la ejecución, consulteEspecifique la configuración del motor Nextflow.
Bloqueo de versiones para ejecuciones activas
La ejecución de un flujo de trabajo siempre finaliza en la versión del motor y en las versiones del plugin con las que comenzó. Esto se aplica a todas las transiciones de versión, incluidas las actualizaciones de parches, el retiro de versiones y las actualizaciones de complementos. Los cambios de versión se aplican solo a las ejecuciones nuevas que se inicien después de la actualización, nunca a las ejecuciones que ya estén en curso.
Se recomienda fijar la versión de Nextflow al iniciar la ejecución
Le recomendamos encarecidamente que fije una versión exacta de Nextflow en tiempo de ejecución y que pruebe las versiones más recientes con bastante antelación a la fecha de caducidad. Para obtener más información, consulte Especifique la configuración del motor Nextflow.
Retirada acelerada de la versión del motor
AWS se reserva el derecho de iniciar el retiro acelerado de una versión del motor de Nextflow en casos excepcionales en los que una versión no pueda mantenerse de acuerdo con los estándares operativos y AWS de seguridad.
En estos casos:
-
Si está utilizando las versiones afectadas, se le notificará inmediatamente cuando se determine la jubilación acelerada.
-
Se aplica un calendario de jubilación reducido, con un período de preaviso mínimo de 90 días siempre que sea posible desde el punto de vista operativo.
-
HealthOmics proporciona orientación sobre la migración y, cuando es posible, herramientas de actualización automatizadas para ayudarlo.
Versiones del motor de parches
Las versiones de parches (por ejemplo, de la versión 24.10.0 a la versión 24.10.8) se actualizan de forma transparente como parte HealthOmics del mantenimiento rutinario del servicio. Las versiones de parches contienen correcciones de seguridad, correcciones de errores y actualizaciones de dependencias. No introducen cambios importantes.
No se aplica ningún proceso de notificación a los clientes o de retiro a las actualizaciones de los parches. Siempre ejecutas el parche seguro más reciente en la versión seleccionada.
Versiones de especificación DSL
Como Nextflow reúne el lenguaje de especificación y el motor en una sola aplicación, la compatibilidad con las versiones de DSL está directamente vinculada a la compatibilidad con las versiones del motor:
-
DSL 1: compatible exclusivamente con la versión 22.04. Cuando se retira la versión 22.04, finaliza el soporte para DSL 1. Debe migrar a DSL 2.
-
DSL 2 — Legacy Parser (Syntax V1): compatible con las versiones 22.04 y 26.04. En la versión 26.04, el analizador antiguo requiere la suscripción explícita.
engineSettings.syntaxVersion = v1 -
DSL 2: analizador estricto (sintaxis V2): predeterminado en la versión 26.04 y en todas las versiones futuras.
Prueba antes de actualizar
Antes de actualizar a una versión más reciente de Nextflow, te recomendamos que:
-
Puede usar los servidores HealthOmics MCP para actualizar y validar sus flujos de trabajo comparándolos con una versión más reciente, lo que incluye comprobar los cambios más importantes y la compatibilidad de las versiones. Puede usar los servidores MCP a través de la CLI de Kiro, Claude Code o cualquier otro MCP-compatible punto final de la agencia.
-
Utilice el
engineSettings.engineVersionparámetroStartRunpara probar los flujos de trabajo con una versión más reciente sin cambiar la definición del flujo de trabajo. Para obtener más información, consulte Especifique la configuración del motor Nextflow. -
Consulta las guías de migración de Nextflow
para ver los cambios importantes entre versiones. -
Para los flujos de trabajo que pasen de la versión 25.10 o anterior a la versión 26.04, pruebe la compatibilidad con el analizador estricto (V2) o configúrelo explícitamente en.
syntaxVersionv1 -
Para los flujos de trabajo en DSL 1 (v22.04), consulta la guía Cómo migrar desde DSL 1 antes de realizar la actualización.
Versiones del complemento Nextflow
HealthOmics preinstala un conjunto seleccionado de complementos de Nextflow para cada versión de motor compatible. El conjunto de complementos es específico para cada versión del motor y no se puede modificar.
| Engine version (Versión del motor) | Pre-installed complementos |
|---|---|
| v2.04 | Sin soporte para complementos |
| v23.10 | nf-schema @2 .3.0, validación nf @1 .1.1 |
| v24.10 | nf-schema @2 .3.0 |
| v2.5.10 | nf-schema @2 .6.1, nf-core-utils @0 .4.0, nf-prov @1 .7.0, nf-fgbio @1 .0.1 |
| versión 2.6.04 | nf-schema @2 .7.2, nf-core-utils @0 .4.0, nf-prov @1 .7.0, nf-fgbio @1 .0.1 |
nota
Para Nextflow v24.10 y versiones posteriores, nf-schema reemplaza al obsoleto complemento nf-validation. Solo puedes usar nf-validation en la versión 23.10.
Cómo se administran las versiones de los complementos de Nextflow
HealthOmics mantiene una versión de complemento por versión de motor:
-
Versión única por complemento por motor: solo está disponible la versión preinstalada que aparece en la tabla anterior.
-
Solo se admiten los complementos preinstalados; solo HealthOmics admite los complementos enumerados en la tabla anterior para cada versión del motor. No se admiten las declaraciones de complementos
nextflow.configque haga referencia a complementos que no estén preinstalados para la versión de su motor. -
Actualizaciones automáticas: cuando se HealthOmics actualiza la versión del complemento preinstalada para un motor, todos los flujos de trabajo de ese motor utilizan la versión actualizada en su próxima ejecución.
-
Sin opciones de activación o exclusión: las actualizaciones de los complementos se aplican de manera uniforme. No existe ningún mecanismo para mantener una versión anterior de un plugin ni una opción de disponibilidad de versión ampliada para los plugins.
-
Bloqueo de versiones para ejecuciones activas: una ejecución de flujo de trabajo que se inicia en una versión de complemento determinada finaliza en esa versión, incluso si el complemento se actualiza durante la ejecución. Las actualizaciones solo se aplican a las ejecuciones nuevas que se inicien después de la actualización.
¿Qué ocurre cuando se actualiza la versión de un plugin
Cambios principales en la versión (por ejemplo, de nf-schema 2.x a 3.x):
-
Se avisa con un mínimo de 30 días de antelación antes de que se aplique la versión principal.
-
Durante el período de gracia de 30 días, la versión principal anterior permanece en uso. Sus flujos de trabajo seguirán usando la versión anterior hasta que finalice el período de gracia.
-
Tras el período de gracia, la nueva versión principal reemplaza a la versión anterior en todos los flujos de trabajo.
-
Las notificaciones anticipadas se envían por correo electrónico, por correo electrónico, por medio de anuncios en el panel de AWS estado y en la consola.
Actualizaciones menores y de parches (por ejemplo, de nf-schema 2.3.0 a 2.7.2): se aplican automáticamente sin previo aviso. Estas actualizaciones no introducen cambios importantes.
Probando los cambios en los complementos
Cuando se anuncia un cambio importante en la versión del plugin (periodo de gracia de 30 días), recomendamos lo siguiente:
-
Consulta las notas de la versión del plugin para ver los cambios más importantes y las directrices de migración.
-
Comprueba tus flujos de trabajo con la nueva versión del plugin antes de que finalice el período de gracia.
-
En el caso de cambios importantes en nf-schema, comprueba que las definiciones de validación de parámetros de tu canalización sean compatibles con el formato de esquema de la nueva versión.
