Règles d'assistance et d'abandon des logiciels

Ce document décrit la politique d'assistance logicielle et le règlement relatif aux abandons de Google Distributed Cloud (GDC) sous air gap.

  1. GDC préviendra de toute modification majeure au moins un an à l'avance. Cet avis peut être émis à tout moment après la mise à disposition générale d'un service ou d'une fonctionnalité, mais la modification elle-même ne prendra effet qu'à la fin de la période de préavis d'un an. Si un avis d'abandon est émis immédiatement après la mise à disposition générale d'un service, il y aura une période d'un an avant la mise hors service du service.

  2. GDC fournira une assistance pendant un an pour chaque version mineure de toute fonctionnalité ou tout service disponible pour tous les utilisateurs. La période d'assistance commence lorsque la fonctionnalité du composant ou une version mineure est officiellement publiée dans le cadre d'une version GDC, et non lorsqu'elle est déployée par l'utilisateur. Certaines fonctionnalités peuvent être disponibles pendant une période de grâce supplémentaire spécifique au service après la fin de la période d'assistance officielle et avant la mise hors service de la version de la fonctionnalité. Pendant cette période de grâce, les versions non compatibles des composants logiciels ne seront pas corrigées ni prises en charge. Toutefois, les logiciels et la documentation resteront disponibles pour permettre aux utilisateurs de passer à une version compatible.

  3. GDC se réserve le droit de demander aux utilisateurs de migrer vers une fonctionnalité plus récente ou une version mineure pour atténuer le risque de failles de sécurité critiques qui ne peuvent pas être corrigées dans les anciennes fonctionnalités ou versions mineures. Cela se produit rarement, mais il est parfois impossible d'appliquer des correctifs de sécurité aux anciennes fonctionnalités ou versions mineures des composants. Il est donc important de prendre des mesures pour protéger les données et les charges de travail des utilisateurs.

  4. Les correctifs de sécurité seront fournis conformément aux objectifs de niveau de service (SLO) applicables pour les fonctionnalités en preview et en disponibilité générale. Toutefois, les engagements du contrat de niveau de service (SLA) de GDC ne s'appliquent pas aux fonctionnalités en preview. Les contrats de niveau de service ne s'appliquent qu'aux fonctionnalités en disponibilité générale.

  5. Les fonctionnalités qui n'existent qu'en preview peuvent être abandonnées ou supprimées sans préavis. La rétrocompatibilité peut ne pas être maintenue lorsque les fonctionnalités passent d'une version preview à une autre ou à différentes versions de l'API preview. Les versions des fonctionnalités en preview seront arrêtées une fois que leurs fonctionnalités auront été intégrées à la version stable.

  6. Les versions GDC (fonctionnalités, versions mineures et correctifs) doivent être appliquées par les opérateurs d'infrastructure (IO) au déploiement et aux organisations associées dès que possible. La version GDC est une version interne et n'est visible que par les opérateurs d'infrastructure.

    1. Une nouvelle fonctionnalité GDC ou une version mineure doit être appliquée dans les 60 jours suivant la publication de la version et, au plus tard, dans les 120 jours (période de grâce), sauf indication contraire de l'équipe GDC.

    2. Une nouvelle version de correctif GDC doit être appliquée dès que possible, en particulier si la version contient des correctifs critiques nécessaires à la sécurité et à la conformité. Les versions de correctif GDC peuvent être ignorées pour rattraper la dernière version. Toutefois, les fonctionnalités ou les versions mineures ne peuvent pas être ignorées et chaque version doit être appliquée.

  7. Les administrateurs de plate-forme (PA) sont responsables de la fourniture de fenêtres de maintenance (MW) adéquates pour l'organisation ou la plate-forme, afin que l'opérateur et l'automatisation puissent appliquer rapidement les mises à niveau et les correctifs.

  8. Les opérateurs d'infrastructure (IO) doivent passer à la dernière version de correctif disponible pour chaque fonctionnalité ou version mineure, sauf indication contraire explicite de GDC, afin d'éviter de manquer des correctifs de sécurité et de bugs.