View a markdown version of this page

Politique de conservation des versions de Nextflow - AWS HealthOmics
Versions du moteur Nextflow prises en chargeCombien de temps les versions du moteur Nextflow restent-elles disponiblesCycle de vie de dépréciationRetrait accéléré de la version du moteurVersions du moteur de correctifsVersions des spécifications DSLTester avant la mise à niveauVersions du plug-in Nextflow

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Politique de conservation des versions de Nextflow

Versions du moteur Nextflow prises en charge

HealthOmics prend en charge plusieurs versions stables du moteur Nextflow. Chaque version prend en charge une ou plusieurs versions de langage spécifique à un domaine (DSL). Le tableau suivant indique les versions actuellement prises en charge.

Version Support DSL HealthOmics date de sortie Statut
version 22.04 DSL 1 ET DSL 2 Novembre 2022 La mise en dépréciation est prévue pour le 30 novembre 2026
Version 23.10 DSL 2 Octobre 2024 La mise en dépréciation est prévue pour le 30 novembre 2027
Version 24.10 DSL 2 août 2025 Pris en charge jusqu'en novembre 2027 au moins
version 25.10 DSL 2 Avril 2026 Pris en charge jusqu'en octobre 2028 au moins
version 26.04 DSL 2 juin 2026 Dernière version, prise en charge jusqu'en avril 2029 au moins

HealthOmics ne prend pas en charge les versions « Edge » mensuelles. HealthOmics prend en charge les fonctionnalités publiées dans chaque version, mais pas les fonctionnalités de prévisualisation.

Une version peut rester disponible pour exécuter des flux de travail une fois qu'elle n'est plus prise en charge. Les versions prises en charge (l'année civile en cours et les deux années précédentes) bénéficient de nouvelles fonctionnalités et d'améliorations de compatibilité. Deprecated-but-available les versions ne reçoivent que des correctifs de sécurité.

Combien de temps les versions du moteur Nextflow restent-elles disponibles

HealthOmics prend en charge les versions de Nextflow publiées au cours de l'année civile en cours, ainsi que les versions publiées au cours des deux années précédentes. Seules ces versions prises en charge bénéficient de mises à jour de fonctionnalités et d'améliorations de rétrocompatibilité. Dans la pratique :

  • En 2026 : les familles d'années prises en charge sont 26,x, 25x et 24x.

  • En 2027 : lors de la sortie de la version 27.04, les familles d'années prises en charge passeront à 27.x, 26.x et 25.x.

Lorsque la première version stable d'une nouvelle année civile est généralement disponible le HealthOmics, la famille des années la plus ancienne est éligible à la dépréciation.

Lorsqu'une version reçoit un avis de dépréciation (entre dans la période de préavis de T—12 à T—0), la maintenance est limitée aux correctifs de sécurité uniquement. Les nouvelles fonctionnalités ne sont pas ajoutées aux versions obsolètes.

Cycle de vie de dépréciation

Lorsqu'une version de Nextflow doit devenir obsolète le HealthOmics, vous bénéficiez d'un délai de préavis minimum de 12 mois. Ceci est suivi d'une période de disponibilité de la version étendue pouvant aller jusqu'à 24 mois, répartis en trois phases distinctes.

Phase Chronologie Disponibilité des versions Maintenance Tarification Création de flux de travail Commencer une course Votre action
Phase 1 : Période de préavis T—12 et T—0 Entièrement fonctionnel pour les flux de travail existants à un prix standard Correctifs de sécurité uniquement Tarif standard (sans changement) Non disponible sur les versions obsolètes Entièrement fonctionnel pour les flux de travail existants Migrez pour éviter les tarifs de disponibilité des versions étendues
Phase 2 : disponibilité de la version étendue T—0 à T+24 mois Entièrement fonctionnel pour les flux de travail existants au tarif de disponibilité des versions étendues Correctifs de sécurité uniquement 2 fois (mois 0 à 12), 4 fois (mois 12 à 24) Non disponible sur les versions obsolètes Entièrement fonctionnel pour les flux de travail existants, soumis à la tarification de disponibilité des versions étendues Démarrez de nouvelles exécutions sur les versions prises en charge ou mettez à niveau la version par défaut du flux de travail pour quitter la tarification de disponibilité des versions étendues
Phase 3 : Fin de vie Après T+24 mois Supprimé du service Aucune N/A — les courses échouent Non disponible sur les versions obsolètes Les exécutions échouent sur les versions non prises en charge (ou retirées) Vous devez effectuer une mise à niveau pour reprendre les exécutions ou en démarrer de nouvelles sur les versions prises en charge

Phase 1 : Période de préavis (T—12 à T—0)

Pendant la période de préavis :

  • Si vous utilisez la version obsolète, vous recevez des communications concernant la chronologie et les flux de travail concernés par e-mail, AWS Health Dashboard et des bannières intégrées à la console.

  • La version reste fonctionnelle pour les flux de travail existants à un prix standard.

  • Vous ne pouvez pas créer de nouveaux flux de travail sur des versions obsolètes, mais vous pouvez lancer de nouvelles exécutions sur des flux de travail existants à un tarif standard.

  • Seuls les correctifs de sécurité sont appliqués. Aucune nouvelle fonctionnalité ni correction de bogues n'est fournie pour la version obsolète.

  • Nous vous recommandons de tester et de migrer vers une version plus récente prise en charge.

  • Vous recevez des rappels pour migrer les flux de travail qui utilisent la version obsolète.

Phase 2 : disponibilité de la version étendue (T—0 à T+24 mois)

Après la date de dépréciation (T) :

  • Toutes les nouvelles exécutions démarrées avec des versions obsolètes sont soumises à un tarif de disponibilité des versions étendues. Vous pouvez éviter cette tarification en démarrant de nouvelles exécutions sur les versions prises en charge ou en mettant à niveau votre flux de travail pour utiliser une version prise en charge.

  • Vous ne pouvez pas créer de nouveaux flux de travail sur les versions obsolètes.

  • Seuls les correctifs de sécurité sont appliqués. Aucune nouvelle fonctionnalité ni correction de bogues n'est fournie pour la version obsolète.

  • Vous recevez des notifications concernant les tarifs de disponibilité des versions étendues si vos flux de travail continuent d'utiliser des versions obsolètes. Le tarif de disponibilité des versions étendues n'est appliqué que si de nouvelles exécutions sont démarrées avec des versions obsolètes au cours de cette phase.

  • Pour démarrer une exécution sur les versions prises en charge, voir l'épinglage de la version du moteur Nextflow. Spécifier les paramètres du moteur Nextflow

Le tableau suivant récapitule les tarifs de disponibilité des versions étendues.

Période Tarification
T—0 à T+12 mois 2 fois le taux de base pour les nouvelles exécutions sur des versions non prises en charge
T+12 à T+24 mois Taux de base multiplié par 4 pour les nouvelles exécutions sur des versions non prises en charge

Phase 3 : Fin de vie (après T+24 mois)

À la fin de la période de disponibilité de la version étendue :

  • Vous recevez une notification finale concernant le retrait de la version si un flux de travail utilise toujours la version retirée.

  • La version est complètement supprimée du service. Vous ne pouvez pas créer de nouveaux flux de travail ni démarrer de nouvelles exécutions sur la version obsolète.

  • Les définitions de flux de travail existantes restent accessibles mais ne s'exécutent pas sur la version supprimée.

  • Vous devez mettre à niveau votre flux de travail pour utiliser une version du moteur prise en charge ou y intégrer une version prise en chargeStartRun. Pour plus d'informations sur l'épinglage de version au début de l'exécution, consultezSpécifier les paramètres du moteur Nextflow.

Verrouillage de version pour les courses actives

L'exécution d'un flux de travail se termine toujours sur la version du moteur et les versions de plug-in avec lesquelles il a commencé. Cela s'applique à toutes les transitions de version, y compris les mises à jour des correctifs, le retrait de version et les mises à jour des plugins. Les modifications de version s'appliquent uniquement aux nouvelles exécutions initiées après la mise à jour, jamais aux exécutions déjà en cours.

L'épinglage de la version Nextflow au démarrage et à l'exécution est recommandé

Nous vous recommandons vivement d'épingler une version exacte de Nextflow au moment de l'exécution et de tester les nouvelles versions bien avant toute date de dépréciation. Pour plus d’informations, consultez Spécifier les paramètres du moteur Nextflow.

Retrait accéléré de la version du moteur

AWS se réserve le droit de procéder à un retrait accéléré d'une version du moteur Nextflow dans les rares cas où une version ne peut pas être maintenue conformément aux normes de AWS sécurité et opérationnelles.

Dans de tels cas :

  • Si vous utilisez les versions concernées, vous êtes immédiatement averti dès qu'il a été décidé de procéder à une mise hors service accélérée.

  • Un calendrier de retraite réduit s'applique, avec un délai de préavis minimum de 90 jours chaque fois que cela est faisable sur le plan opérationnel.

  • HealthOmics fournit des conseils en matière de migration et, dans la mesure du possible, des outils de mise à niveau automatisés pour vous aider.

Versions du moteur de correctifs

Les versions des correctifs (par exemple, v24.10.0 à v24.10.8) sont mises à niveau de manière transparente dans le cadre de la maintenance de HealthOmics routine. Les versions de correctifs contiennent des correctifs de sécurité, des corrections de bogues et des mises à jour de dépendances. Ils n'introduisent pas de changements radicaux.

Aucune notification aux clients ni aucun processus de retrait ne s'applique aux mises à niveau des correctifs. Vous exécutez toujours le dernier correctif sécurisé dans la version que vous avez sélectionnée.

Versions des spécifications DSL

Comme Nextflow regroupe le langage de spécification et le moteur dans une seule application, la prise en charge de la version DSL est directement liée à la prise en charge de la version du moteur :

  • DSL 1 — Pris en charge exclusivement sur la version 22.04. Lorsque la version 22.04 est retirée, le support DSL 1 prend fin. Vous devez migrer vers le DSL 2.

  • DSL 2 — Legacy Parser (syntaxe V1) — Supporté sur les versions 22.04 à 26.04. Sur la version 26.04, l'ancien analyseur nécessite une inscription explicite. engineSettings.syntaxVersion = v1

  • DSL 2 — Strict Parser (Syntax V2) — Par défaut sur la v26.04 et toutes les versions futures.

Tester avant la mise à niveau

Avant de passer à une version plus récente de Nextflow, nous vous recommandons de :

  • Vous pouvez utiliser les serveurs HealthOmics MCP pour mettre à niveau et valider vos flux de travail par rapport à une version plus récente, notamment pour vérifier l'absence de modifications majeures et la compatibilité des versions. Vous pouvez utiliser les serveurs MCP via Kiro CLI, Claude Code ou tout autre point de terminaison MCP-compatible agentic.

  • Utilisez le engineSettings.engineVersion paramètre in StartRun pour tester les flux de travail par rapport à une version plus récente sans modifier la définition de votre flux de travail. Pour plus d’informations, consultez Spécifier les paramètres du moteur Nextflow.

  • Consultez les guides de migration de Nextflow pour connaître les modifications les plus importantes entre les versions.

  • Pour les flux de travail passant de la version 25.10 ou antérieure à la version 26.04, testez la compatibilité avec le Strict Parser (V2) ou définissez explicitement sur. syntaxVersion v1

  • Pour les flux de travail sur DSL 1 (v22.04), suivez le guide de migration depuis DSL 1 avant de procéder à la mise à niveau.

Versions du plug-in Nextflow

HealthOmics préinstalle un ensemble organisé de plugins Nextflow pour chaque version de moteur prise en charge. L'ensemble de plugins est spécifique à chaque version du moteur et ne peut pas être modifié.

Version de moteur Pre-installed plugins
version 22.04 Pas de support pour les plugins
Version 23.10 nf-schema @2 .3.0, nf-validation @1 .1.1
Version 24.10 schéma nf @2 .3.0
Version 25.10 nf-schema @2 .6.1, nf-core-utils @0 .4.0, nf-prov @1 .7.0, nf-fgbio @1 .0.1
version 26.04 nf-schema @2 .7.2, nf-core-utils @0 .4.0, nf-prov @1 .7.0, nf-fgbio @1 .0.1
Note

Pour Nextflow v24.10 et versions supérieures, nf-schema remplace le plugin nf-validation obsolète. Vous ne pouvez utiliser nf-validation que sur la version 23.10.

Comment sont gérées les versions du plugin Nextflow

HealthOmics gère une version de plug-in par version de moteur :

  • Version unique par plug-in et par moteur — Seule la version préinstallée répertoriée dans le tableau précédent est disponible.

  • Seuls les plugins préinstallés sont pris en charge. Seuls HealthOmics les plugins répertoriés dans le tableau précédent sont pris en charge pour chaque version du moteur. Les déclarations de plug-in figurant dans votre nextflow.config compte qui font référence à des plugins non préinstallés pour la version de votre moteur ne sont pas prises en charge.

  • Mises à jour automatiques  : lors de la HealthOmics mise à jour de la version du plug-in préinstallée pour un moteur, tous les flux de travail de ce moteur utiliseront la version mise à jour lors de leur prochaine exécution.

  • Aucun opt-in ou opt-out — Les mises à jour des plugins sont appliquées de manière uniforme. Il n'existe aucun mécanisme permettant de conserver une version précédente du plugin et aucune option de disponibilité des versions étendues pour les plugins.

  • Verrouillage de version pour les exécutions actives  : une exécution de flux de travail qui démarre sur une version de plug-in donnée se termine sur cette version, même si le plug-in est mis à jour pendant l'exécution. Les mises à jour s'appliquent uniquement aux nouvelles exécutions initiées après la mise à jour.

Que se passe-t-il lorsqu'une version d'un plugin est mise à jour

Changements de version majeurs (par exemple, nf-schema 2.x à 3.x) :

  • Un préavis d'au moins 30 jours est fourni avant l'application de la version majeure.

  • Pendant la période de grâce de 30 jours, la version majeure précédente reste utilisée. Vos flux de travail continuent d'utiliser la version précédente jusqu'à la fin de la période de grâce.

  • Après la période de grâce, la nouvelle version majeure remplace la version précédente pour tous les flux de travail.

  • La notification préalable est communiquée par e-mail, par le tableau de bord AWS de santé et par des bannières intégrées à la console.

Mises à jour mineures et correctifs (par exemple, nf-schema 2.3.0 à 2.7.2) : appliquées automatiquement sans préavis. Ces mises à jour n'introduisent pas de modifications majeures.

Tester les modifications apportées au plugin

Lorsqu'un changement majeur de version du plugin est annoncé (délai de grâce de 30 jours), nous recommandons ce qui suit :

  • Consultez les notes de mise à jour du plugin pour connaître les modifications les plus importantes et les conseils de migration.

  • Testez vos flux de travail par rapport à la nouvelle version du plug-in avant la fin de la période de grâce.

  • Pour les modifications majeures apportées à nf-schema, vérifiez que les définitions de validation des paramètres de votre pipeline sont compatibles avec le format de schéma de la nouvelle version.