Modèle de stabilité

plugin-kit-ai utilise des termes contractuels formels afin que les équipes puissent décider exactement ce qu'elles souhaitent normaliser.

Langage public versus langage formel

Les documents publics utilisent un vocabulaire de premier passage plus simple :

Recommended pointe généralement vers les chemins public-stable de courant le plus fort
Advanced pointe vers des surfaces supportées plus étroites ou plus spécialisées
Experimental correspond à public-experimental

Lorsque vous définissez une politique de compatibilité, les termes formels l'emportent.

Recommended est le langage du produit et ne remplace pas le contrat formel.

cela signifie généralement un chemin de production promu public-stable
cela ne signifie pas la parité entre toutes les cibles
il ne met pas à niveau les surfaces public-beta ou public-experimental par le seul libellé

Considérez public-stable comme le niveau sur lequel vous pouvez construire avec des attentes de production normales.

Il s’agit du niveau que la plupart des équipes devraient préférer pour les normes par défaut et le déploiement à long terme.

Traitez public-beta comme pris en charge, mais pas gelé.

Utilisez la version bêta uniquement lorsque le compromis est explicite et en vaut la peine pour le produit.

Traitez public-experimental comme une désabonnement opt-in en dehors des attentes normales de compatibilité.

Cela peut être utile pour l’apprentissage ou l’adoption précoce, mais cela ne devrait pas devenir la valeur par défaut de l’équipe.

Préférez le chemin recommandé pour le produit que vous créez.
Utilisez les termes formels exacts uniquement lorsque vous avez besoin de précisions en matière de politique ou de compatibilité.
Utilisez validate --strict comme porte de préparation pour le dépôt que vous prévoyez d'expédier.