Cline v4.0.1, publié le 28 juin 2026, est l'une des publications stables les plus inhabituelles de l'histoire récente de l'outillage IA. Ses notes de version tiennent en une ligne : « Roll the stable VS Code extension back to the pre-SDK-migration codebase to resolve regressions reported in 4.0.0. This release ships the 3.89.2 extension code under a higher version number so existing 4.0.0 users receive the update. SDK-migration work continues separately on main. » Quarante-huit heures plus tôt, Cline v4.0.0 avait migré l'extension VS Code sur le SDK Cline partagé, le changement d'architecture phare couvert dans l'article Cline 4.0 du 27 juin. v4.0.2, publié le 29 juin (le jour où cet article sort), ramène le chemin de code basé sur le SDK avec le support de l'effort de raisonnement pour les modèles thinking de DeepSeek, une couche de raisonnement ClinePass centralisée, et une série de correctifs pour les fournisseurs et la webview. La séquence de 72 heures est un exemple travaillé de la façon dont une migration majeure peut être récupérée sans annuler le travail lui-même.
Ce que l'annulation a réellement livré
La migration SDK de 4.0.0 était en chantier depuis des mois ; la vue de comparaison entre v3.89.2 et v4.0.0 montre que l'extension entière est passée de son implémentation de tâches historique basée sur npm à un runtime TypeScript partagé qui alimente aussi la CLI Cline, Kanban et le plugin JetBrains. Dans les heures qui ont suivi la publication stable, deux issues GitHub ont décrit des régressions que les utilisateurs existants de la 3.x ne voyaient pas. L'issue #11934, ouverte le matin après la sortie de 4.0.0, signalait que « all file-change reviews stopped showing diffs in VS Code. Instead of displaying the usual side-by-side or inline diff, Cline only presented Approve or Reject buttons with no diff view at all in the editor window. » L'issue #11907, ouverte tard le 27 juin, signalait des erreurs run_commands pendant les éditions de fichiers sur des modèles Qwen locaux. Les deux rapporteurs notaient que revenir à 3.89.2 rétablissait immédiatement le comportement normal.
Les commentaires de suivi sur #11907 sont ce qui a façonné la décision d'annuler. Un commentateur utilisant GLM 5.2 et MiniMax M3 via Ollama a écrit qu'après la mise à jour 4.0 Cline était devenu « basically unusable » parce que « file editing no longer works reliably at all : the VS Code diff preview is gone or not shown properly, edits are not applied, and the new CLI/tool-based flow fails with these models. » Le commentaire pointait vers le commit #11801 comme coupable probable, et proposait un correctif manuel de la distribution bundled @cline/core. C'est le type de signalement qu'un projet ne veut pas traiter un utilisateur à la fois. Le correctif était structurel : faire avancer l'extension legacy et laisser le travail SDK sur main.
La branche legacy-extension et un workflow de publication dédié
Le mécanisme est la partie intéressante. Cline n'a annulé aucun commit sur main ; le travail de migration SDK a continué sur place. À la place, le projet a créé une branche séparée legacy-extension qui contient la base de code 3.89.x basée sur npm, et un nouveau workflow ext-vscode-publish-legacy.yml qui publie depuis cette branche. Le commentaire du workflow explique le choix de conception :
Publishes the legacy (pre-SDK-migration) VS Code extension from the
legacy-extensionbranch. This branch holds the npm-based 3.89.x codebase, rolled forward under a 4.0.x version so existing 4.0.0 users still receive the update. The mainext-vscode-publish-stable.ymlworkflow (bun-based) stays the path for releasingmainonce the SDK migration is solid.
Le workflow inline aussi sa propre suite de tests npm de l'extension legacy plutôt que de réutiliser le .github/workflows/ext-vscode-test.yml partagé, parce que cette suite sur main est basée sur Bun et testerait la mauvaise branche. Le workflow legacy checkout la branche legacy-extension, exécute npm --prefix apps/vscode ci, puis exécute npm run ci:check-all, npm run ci:build, les tests unitaires, les tests d'intégration de l'extension et les tests de la webview. Le tag de release est dérivé de la version du package sur la branche legacy, le changelog doit commencer par le nouveau titre de version, et le tag n'est créé que s'il n'existe pas déjà sur origin. C'est la forme en production d'une récupération de type « il faut faire avancer l'ancien code pendant qu'on corrige le nouveau ».
La vue de comparaison entre v4.0.0 et v4.0.1 est en conséquence courte : un seul commit chore(vscode): bump to 4.0.1 for legacy rollback release, plus les bumps de CHANGELOG.md et apps/vscode/package.json. Tout le reste est sur la branche legacy-extension. Le même schéma explique pourquoi un tag 4.0.1 peut livrer la base de code 3.89.2 : la version est avancée, la branche legacy est la source de vérité, et la migration SDK reste intacte sur main pour le retour stable éventuel.
Ce que v4.0.2 a ramené
v4.0.2, publié le matin du 29 juin, ramène le chemin de code basé sur le SDK sur la branche legacy avec huit commits de correctifs et de fonctionnalités. La vue de comparaison entre v4.0.1 et v4.0.2 est le vrai signal que la migration SDK est en cours de stabilisation plutôt qu'abandonnée.
La fonctionnalité phare est le support de l'effort de raisonnement incluant xhigh pour les modèles thinking de DeepSeek (#11938). La PR ajoute un sélecteur d'effort de raisonnement limité aux modèles capables de thinking et un correctif qui ne transmet pas none à l'API du fournisseur, pour que le modèle lui-même, pas le wrapper du fournisseur, décide quand sauter la sortie de raisonnement. Une PR de suivi (#11954) centralise la couche de support de l'effort de raisonnement pour que le même composant gère le paramètre entre ClinePass et les fournisseurs directs, avec un correctif qui expose les contrôles d'effort de raisonnement pour les modèles ClinePass et normalise le flag include du raisonnement budget de Claude.
Trois autres commits serrent la surface des fournisseurs ClinePass et Z.ai. #11950 améliore l'UX du fournisseur ClinePass avec une étape intermédiaire avant la sélection de modèle et un chemin de repli pour les actions ClinePass. #11951 préfère les identifiants Z.ai canoniques et supprime le filtrage d'alias redondant côté Cline. #11958 polit les métadonnées ClinePass et Z.ai. #11955 corrige le remplacement des variables d'environnement dans la webview, qui s'était silencieusement cassé pour l'interpolation de templates dans l'extension basée sur le SDK. #11960 définit les paramètres par défaut de focus chain dans l'état de la webview pour que le toggle reflète la bonne valeur au chargement.
Le commit de release, chore(vscode): bump to 4.0.2 for legacy release, est du même type que le bump de version de 4.0.1, mais le diff dans la vue de comparaison rend clair que 4.0.2 n'est plus une annulation pure ; c'est le chemin de code du SDK qui revient sur la branche legacy avec une série de correctifs que le projet a collectés pendant que l'extension stable tournait sur 3.89.x.
CLI v3.0.32 arrive sur SDK v0.0.54 le même jour
La ligne CLI a continué à être publiée sur le SDK partagé pendant toute l'annulation de l'extension, et CLI v3.0.32 est sorti le même matin que v4.0.2 sur SDK v0.0.54. Les notes de version CLI listent cinq changements : une étape intermédiaire avant la sélection de modèle ClinePass, un écran d'abonnement ClinePass sélectionnable, la promotion de ClinePass dans l'avis de démarrage, l'utilisation cohérente de « ClinePass » en un seul mot dans l'interface CLI, et une meilleure précision de compaction de contexte et des messages d'erreur plus clairs tirés de SDK v0.0.54. Le correctif de compaction côté SDK (#11894, la veille) était une amélioration basique du budget de tokens qui a été livrée à la CLI sans attendre que l'annulation de l'extension se stabilise.
Le découpage est instructif. La CLI, Kanban et le plugin JetBrains n'ont jamais été annulés, parce que les régressions de migration SDK sur la surface CLI étaient différentes et moins graves que les régressions d'édition de fichiers et d'aperçu de diff sur l'extension VS Code. Le chemin de publication legacy est spécifique à l'extension, ce qui suggère que la récupération a été motivée par les régressions de diff et d'édition VS Code, pas par une défaillance SDK plus générale.
À surveiller
Trois signaux à monitorer sur la semaine à venir. Premièrement, quand la prochaine release de l'extension VS Code sortira du workflow principal ext-vscode-publish-stable.yml plutôt que du workflow legacy, la migration SDK sera considérée comme stabilisée. Le workflow legacy note explicitement qu'il sert à « releasing main once the SDK migration is solid », donc le chemin de retour est observable dans l'onglet Actions. Deuxièmement, surveillez la fermeture des threads #11934 et #11907 par un correctif 4.0.x plutôt qu'un patch manuel ; si le lot de huit commits de 4.0.2 les ferme, les régressions d'édition de fichiers sont résolues. Troisièmement, la ligne SDK (@cline/sdk) est désormais publique pour les développeurs qui construisent leurs propres agents, et la release v0.0.54 a été la première release SDK livrée en parallèle d'une extension connue cassée ; si v0.0.55 ou v0.0.56 inclut une note « tested against the stable extension », les lignes extension et SDK ont reconvergé.
La leçon plus large est structurelle. Quand une migration majeure casse le chemin stable, l'option la moins coûteuse est d'annuler la migration et de recommencer ; Cline a plutôt détaché le chemin de publication (branche legacy, workflow dédié, suite de tests inline) et laissé le travail SDK continuer sur main pendant que les utilisateurs 3.89.x recevaient les mises à jour. Le même schéma est apparu chez OpenAI avec le travail de gouvernance Codex 0.142 quand le relais Noise 0.141 a été livré en premier pour durcir le transport, et chez Vinext avec le travail d'adaptateurs Cloudflare/Vercel quand le framework a livré les adaptateurs avant la consolidation du runtime. Le point est que la forme des migrations de 2026, à travers Astro 7 et son compilateur Rust Vite 8, les progrès incrémentaux de tree-shake d'Oxc, et maintenant le passage au SDK de Cline, est une séquence de grosses réécritures d'architecture livrées par étapes plutôt qu'en un seul big bang. Cline 4.0.1 est à quoi ressemble une honnête « étape 1 de la migration » quand le chemin stable doit continuer à fonctionner.
