Contrôle des versions et stabilité

UiPath CLI 1.0.0 suit le contrôle de version sémantique (MAJOR.MINOR.PATCH). Cela remplace le schéma basé sur le calendrier (2023.10, 2024.10, 2025.10) utilisé par l’ancienne CLI.NET. Cette page constitue le contrat - ce sur quoi vous pouvez vous appuyer d’une version à l’autre, ce qui peut changer et comment les versions de l’hôte et de l’outil restent à l’étape.

Ce que signifie le serveur dans la pratique

Champ	Quand cela se produit	Éléments modifiables
MAJOr (1.x.x → 2.0.0)	Modifications radicales des noms de commande, de la sémantique des indicateurs ou de l'enveloppe JSON.	Les commandes peuvent être renommées ou supprimées; les indicateurs peuvent être renommés ou voir leur signification modifiée; les champs de niveau supérieur de l'enveloppe peuvent changer de forme. Un cycle d'obsolescence complet précède toute version MAJOR — les commandes obsolètes continuent de fonctionner dans la INFÉRIEUR dernière de la version MAJOR précédente.
Mineur (1.0.x → 1.1.0)	Nouvelles commandes, nouveaux outils, nouveaux indicateurs, nouvelles sous-commandes.	Additif uniquement sur l'interface de commande. Cependant, la forme de Data à l’intérieur de l’enveloppe JSON est spécifique à la commande et peut changer — de nouveaux champs ont été ajoutés, parfois des champs renommés ou imbriqués. Les scripts qui analysent des noms de champs spécifiques doivent être revalidés lors d'un bogue mineur.
PATCH (1.0.0 → 1.0.1)	Corrections de bogues.	Aucun changement de comportement documenté. Un correctif qui modifie le comportement est traité comme un rapport de bogue relatif au correctif lui-même.

Il n'y a pas d'indicateur --preview (contrairement à Azure CLI). Les commandes de statut d'aperçu sont libellées sur leur page de référence et peuvent changer dans une version mineure sans avertissement - voir Stabilité par commande ci-dessous.

Le contrat stable

Les éléments suivants ne changent pas entre les versions mineures ou PATCH. Écrivez librement un script contre eux.

Champs de l'enveloppe

Chaque commande va générer une enveloppe sur stdout avec ces champs de niveau supérieur:

Champ	Stabilité	Signification
Result	Stable	Success, Failure, ConfigError, AuthenticationError, ValidationError, TimeoutError
Code	Stable dans MAJOR	Identificateur de réussite spécifique à la commande (FolderList, SolutionPack, etc.). De nouveaux codes peuvent apparaître dans les versions mineures pour les nouvelles commandes.
Data	Spécifique à la commande	Format de charge utile défini par chaque commande. Peut ajouter des champs dans les versions mineures. Rarement, les champs peuvent être renommés dans mineur - vérifiez les notes de version.
Message, Instructions	Stable	Texte d'erreur lisible par un humain. Le contenu peut être amélioré d’une version à l’autre; la présence et le rôle ne changent pas.
Context, Log	Stable	Champs facultatifs. Les conditions de présence sont stables.

Voir la section Formats de sortie de l'enveloppe en détail.

Codes de sortie

Le contrat de code de sortie à cinq niveaux (0 / 1 / 2 / 3 / 4 plus 130 pour l'annulation de l'utilisateur) est stable dans une version majeure. 4 est réservé — aucune commande ne l'émet dans 1.x aujourd'hui — mais les scripts qui le gèrent déjà continueront de fonctionner.

Options globales

--output, --output-filter, --log-level, --log-file — ces quatre indicateurs sont stables sur les augmentations mineures. De nouvelles options globales peuvent être ajoutées; ceux existants ne seront pas renommés ou supprimés sans publication majeure.

Séparation stdout/stderr

Stdout est l'enveloppe. stderr correspond aux journaux, à la progression et au texte d'erreur présenté à un humain. Cette séparation s'applique à chaque commande, à chaque format et à chaque version.

Versions de l’hôte et de l’outil

L'hôte (@uipath/cli, l'exécutable uip ) et chaque outil (par exemple, @uipath/orchestrator-tool) sont publiés sous forme de packages npm indépendants, chacun avec son propre serveur. Ils sont coordonnés de sorte qu'un hôte au niveau de la version 1.0.x exécute les outils au niveau de 1.0.x.

Résolution de la version par défaut

Lorsque vous exécutez uip tools install <alias> sans version explicite, l’hôte sélectionne la dernière version de l’outil dont MAJOR.MINIOR correspond à la ligne MAJOR.MINOR actuelle de la CLI. La mise à niveau de la CLI de 1.0.x vers 1.1.0 , puis l'exécution de uip tools update place chaque outil installé dans la ligne 1.1.x .

npm install -g @uipath/cli@1.1.0
uip tools update          # all tools → latest 1.1.x

Vous pouvez remplacer la valeur par défaut d’un outil spécifique:

uip tools install orchestrator-tool@1.0.2
uip tools update --name flow-tool --version 1.1.5

Importance de l’épinglage

Les outils communiquent avec l’hôte via un contrat TypeScript avec version (enregistrement de la commande, formatage de sortie, télémétrie, contexte). Si le contrat change entre les versions mineures, l’hôte et l’outil doivent être déplacés ensemble. L'option par défaut d'épinglage des versions garantit qu'ils le font, sans que l'utilisateur ait à y réfléchir.

Canaux

L'hôte reconnaît les npm dist-tags sur les outils:

• latest — la ligne stable (par défaut lorsqu'aucune balise n'est transmise).
• beta — l'aperçu des versions avant la ligne stable.
• alpha — l'accès précoce, les versions instables.

uip tools install flow-tool@beta
uip tools update --name flow-tool --version alpha

Les canaux sont au niveau de l'outil, et non au niveau de l'hôte. Vous pouvez combiner un hôte stable avec un outil bêta pour un workflow spécifique, sachez que la combinaison est moins bien testée.

Stabilité par commande

Les commandes et les indicateurs individuels comportent l'un des trois libellés de stabilité. Recherchez-les en haut de la page de référence de chaque commande.

Label	Signification
Disponibilité générale (par défaut; sans libellé)	La commande est couverte par le contrat du serveur ci-dessus. Il ne sera pas renommé ou supprimé dans une version MAJOR.
Aperçu	La commande est en développement actif. Les indicateurs, les valeurs par défaut et la forme de sortie peuvent changer sans augmentation majeure, bien que les changements radicaux soient rares et annoncés dans les notes de publication. Utilisez-les en production uniquement lorsque vous êtes prêt à valider à nouveau pour chaque version.
Obsolète	La suppression de la commande est prévue dans la prochaine version MAJOR. Il continue de fonctionner dans la version 1.x et génère un avertissement lors de l'exécution. Utilisez le successeur répertorié dans la note d’obsolescence.

Il s’agit de la même convention qu’utilise GCloud. La UiPath CLI ne gère pas les commandes d'aperçu derrière un indicateur d'inscription - elles sont visibles dans --help et appelables.

Épinglage des recommandations

Pour les pipelines CI:

# pin host version
npm install -g @uipath/cli@1.0.0

# pin each tool you use
uip tools install @uipath/orchestrator-tool@1.0.2 \
                  @uipath/solution-tool@1.0.1

Cela vous donne un environnement reproductible qui survit aux versions en amont. Validez à nouveau après chaque saut de CLI à l'aide des tests d'intégration de votre pipeline; consultez les notes de publication pour connaître les modifications apportées au Dataprofil -forme.

Pour les stations de travail développeur:

npm install -g @uipath/cli@latest
uip tools update    # after each CLI upgrade

Moins reproductible, plus pratique.

Cycle d’obsolescence

Lorsqu'une commande ou un indicateur s'efface, le chemin d'accès est:

1. Obsolescence annoncée : la commande est marquée Deprecated dans sa page de référence, et les notes de version de la version mineure qui a introduit l'obsolescence la listent. Un remplacement est documenté.
2. Avertissement de runtime — uip <deprecated-command> ... continue de fonctionner mais envoie un avertissement sur stderr. Les scripts qui utilisent stdout ne sont pas affectés.
3. Suppression dans la version MAJOR suivante — la commande est supprimée au prochain saut de version MAJOR. Il y a au moins un cycle MAJOR complet entre l'obsolescence et la suppression, suffisamment long pour effectuer la migration de tout pipeline du cycle de vie pris en charge.

Exécutez uip <command> --help pour voir si une commande est obsolète; le libellé apparaît dans la synthèse.

Lorsque la forme des données change

Étant donné que Data est spécifique à la commande et peut changer dans les versions mineures, les pipelines qui extraient des champs spécifiques (--output-filter "Data.Jobs[0].Key") sont les plus exposés à l'affectation mineure. Deux atténuations:

• Épinglez @uipath/cli dans CI (voir ci-dessus). Vous choisissez quand valider les nouvelles formes.
• Requête défensive : préférez les expressions JMESPath qui tolèrent les champs manquants (Data.Jobs[0].Key || '') lorsque vous le pouvez; Consultez les notes de publication avant la mise à niveau.

Les changements de forme Data dans mineur sont rares et signalés dans les notes de publication comme [Data shape] sous la commande modifié(e).

Où surveiller les modifications

• Notes de publication — Résumé par version des commandes ajoutées, des indicateurs modifiés et des changements de forme.
• uip --version et uip tools list — ce qui est actuellement installé sur une machine. Comparez entre les environnements pour capturer la dérive.
• Le package de chaque outil sur npm — les éditeurs répertorient les dist-balises et l'historique des versions.

Voir également

• Formats de sortie — la forme de l'enveloppe décrite dans le contrat.
• Codes de sortie — le contrat à cinq niveaux.
• Outils (extensions) : le modèle d'outil hôte que l'épinglage de version prend en charge.
• Notes de publication — ce qui a changé et quand.
• Migration depuis la version CLI.NET héritée — si vous venez de 2025.10 ou d'une version antérieure.