Résumé

  • Sur NuGet.org, retirer un paquet des listes laisse sa version exacte disponible au téléchargement et à la restauration.
  • L’avis d’obsolescence et le transfert de popularité facilitent le passage à un successeur, sans déplacer les projets des utilisateurs.
  • Une retraite logicielle se paie en travail de migration, en transmission des droits et en conservation du savoir. Une page de catalogue propre ne solde aucune de ces dépenses.

Le directeur financier aimerait une date. L’équipe produit lui offre un bouton. Retirer le vieux paquet du catalogue paraît donner un terme net à une histoire devenue coûteuse : plus de promotion, plus de confusion, toute l’attention sur la nouvelle gamme. Puis un client reconstruit son application avec l’ancienne dépendance.

Dans ce scénario hypothétique, personne n’a saboté le plan. Chacun a simplement exercé un droit différent. L’éditeur a modifié la présentation du paquet. Le client a demandé une version précise. NuGet.org peut satisfaire les deux.

La politique officielle protège la restauration des projets : le retrait des listes ordinaires laisse accessibles le téléchargement, l’installation et la restauration d’une version exacte. Même une restauration à version flottante peut encore retenir un paquet retiré, s’il demeure la version la plus récente répondant aux contraintes. La réplication du catalogue le conserve également.Politique de suppression de NuGet

Le stock de logiciel ressemble ainsi à un magasin dont on peut décrocher l’enseigne sans fermer le comptoir des habitués. Pour ceux qui doivent reconstruire une application ancienne, cette continuité a une valeur très concrète. Pour celui qui veut arrêter de s’en occuper, elle empêche de confondre discrétion commerciale et départ des clients.

Le verbe est plus puissant que la commande

La commande nuget delete porte un nom vigoureux. Son effet dépend de la destination : elle retire des listes sur NuGet.org, mais supprime dans un dossier local.Référence de la commande

Un compte rendu disant « suppression effectuée » laisse donc une question entière derrière lui. Où ? Sur le poste d’un salarié, dans l’affichage public, dans la configuration du client ? La réponse détermine qui devra encore travailler lundi matin.

NuGet réserve des suppressions exceptionnelles à son équipe, notamment pour des contenus nuisibles ou portant atteinte à des droits. La gestion ordinaire d’une gamme vieillissante suit une autre logique. La continuité des dépendances ne serait guère crédible si chaque réorganisation commerciale pouvait effacer les pièces nécessaires aux anciens projets.

Cette règle répartit un pouvoir économique. L’éditeur choisit de moins exposer son produit. Il ne dispose pas, par ce seul geste, du calendrier de migration de ceux qui l’utilisent. Il lui reste à rendre le passage possible, désirable, puis réellement effectué.

Le courrier de départ n’est pas toujours distribué

NuGet propose précisément un avis d’obsolescence, avec un motif et, éventuellement, un paquet de remplacement. Cet avis peut accompagner un retrait des listes ou être utilisé séparément. Son champ de diffusion mérite cependant davantage d’attention que la prose de l’annonce : le message personnalisé est présenté sur NuGet.org, pas dans les clients.Obsolescence et transfert de popularité

Les versions compatibles de Visual Studio affichent des informations d’obsolescence dans la vue des paquets installés. Une commande dotnet permet de rechercher les dépendances concernées. Il faut donc que l’information rencontre un geste de travail. Le fournisseur peut avoir publié une explication impeccable tandis que l’équipe cliente continue d’exécuter sa procédure habituelle sans la consulter.

Le coût se loge dans cet écart. Qui repère l’avis ? Qui choisit le remplaçant ? Qui paie les tests ? Un responsable produit peut économiser une semaine de documentation et la faire dépenser, en morceaux, par plusieurs équipes clientes. Le service d’assistance retrouvera ensuite une partie de cette économie sous forme de questions répétées.

Financer une migration revient à acheter une série de décisions chez autrui. Une bannière est bon marché parce qu’elle n’achète presque rien de tout cela.

On peut transmettre la popularité, pas remplir le carnet de commandes

NuGet permet aussi de demander le transfert du score interne de popularité d’un ancien paquet vers son successeur. Le nouvel arrivant peut ainsi bénéficier de cette histoire dans les résultats de recherche. Les compteurs réels de téléchargements restent inchangés, et les références des projets utilisateurs ne se réécrivent pas.

L’opération est soumise à examen. Tous les propriétaires doivent être communs, la relation entre les paquets doit être claire, les anciennes versions déclarées obsolètes avec un remplacement, et le successeur disposer d’une version stable. La recherche ne doit pas devenir confuse. Un ancien paquet peut transmettre son score à cinq nouveaux au maximum, à parts égales ; un paquet déjà bénéficiaire ne peut pas servir de relais pour une chaîne de transferts.

Cette répartition égale est une petite leçon de stratégie industrielle. Découper une bibliothèque en modules peut obéir à une excellente logique technique. La réputation historique, elle, sera distribuée selon la règle du guichet. Le module auquel la direction prête le plus grand avenir ne reçoit pas automatiquement la plus grosse part.

L’actif transmis est une position de découverte, pas une clientèle captive. Un acquéreur qui additionne un nom de paquet, une place dans les recherches et des utilisateurs supposément acquis risque de compter trois fois une promesse encore à exécuter.

La signature et les clés

La documentation de publication distingue enfin l’auteur indiqué dans les métadonnées du propriétaire disposant des permissions. Pour transmettre le contrôle, on ajoute un nouveau propriétaire, qui accepte l’invitation ; l’ancien peut ensuite être retiré. Une invitation en attente laisse la remise des clés inachevée.Publication et gestion des propriétaires

C’est un détail embarrassant pour une équipe déjà dissoute. Les documents peuvent être transférés, les badges rendus et le discours de départ prononcé, alors que la personne capable de publier reste du mauvais côté de l’organigramme.

La facture propre à un fournisseur exige trois éléments absents de ces règles générales : les dépendances effectivement utilisées, les engagements d’assistance et les migrations achevées. Avec eux, on peut décider qui aider, quelle compétence conserver et à quel moment réduire l’effort. Sans eux, la date de retraite reste un chiffre choisi pour sa beauté dans une présentation.