NuGetの削除では終わらない旧パッケージの引退

要約

棚卸しが終わり、古い製品名がカタログから消える。経営会議には分かりやすい成果だ。ところが顧客が翌朝ビルドをやり直すと、退役したはずの部品がまた届く。

これは特定企業の障害報告ではなく、NuGet.orgの規則から描ける場面である。提供者が整理したのは売り場で、顧客が求めたのは既に決めてある部品だった。両者の操作は衝突せずに成立する。

NuGet.orgでは、通常の削除は掲載を外す処理になる。一般的な検索や表示から退いても、正確なバージョンを指定すればダウンロード、インストール、復元ができる。浮動バージョンの復元でも、条件に合う最新版が掲載を外された版なら選ばれる場合がある。カタログの複製にも含まれる。NuGetの削除方針

昔のプロジェクトを再現したい顧客にはありがたい。昨日使った部品が今日の販売方針で消えるなら、再構築は再開発に近づく。その連続性を守るため、プラットフォームは提供者が日常の管理操作で過去を消す力を制限している。

nuget deleteという命令にも、行き先の区別がある。対象がNuGet.orgなら掲載解除、ローカルフォルダーなら削除になる。同じ動詞でも、及ぶ範囲は同じではない。削除コマンドの公式説明

調達担当者に必要なのは、コマンドの暗記より、その報告を読む力だ。「旧版を削除した」と聞いたら、どこから消えたのかを確かめる。社内のファイルか、公開検索の結果か、それとも顧客側の依存指定が変わったのか。最後の一つまで終わっていなければ、移行作業は残っている。

有害な内容や権利侵害などには、NuGetチームによる例外的な削除の経路がある。通常の製品整理とは別の権限だ。単に採算の悪い旧製品から手を引きたいという都合で、顧客の再現性をまとめて処分できる仕組みにはなっていない。

この制約は、終了計画の作り方を変える。検索から消す日を決めるだけなら提供者の会議で足りる。利用を終えてもらうには、顧客の開発予定、テスト、後継品への評価が必要になる。

NuGetには非推奨を知らせる機能がある。理由を示し、代替パッケージやバージョンを案内できる。掲載解除とは独立しており、両方を行うこともできる。ただし独自に書いたメッセージはNuGet.org上で表示され、クライアントにはその文章がそのまま届かない。非推奨と人気度移転の公式規則

対応するVisual Studioではインストール済みパッケージの画面に情報が表示され、dotnetにも非推奨の依存を調べるコマンドがある。情報を見る場所、調べる動作があって初めて通知は仕事につながる。普段の復元が成功している顧客にとって、提供者の告別文が最優先の読み物になる理由は少ない。

そこへ移行支援の費用が入る。どの版からどこへ移るか、互換性の確認を誰が行うか、テストの失敗を誰が受け持つか。説明を省いた分だけ作業が消えるなら楽だが、実際には顧客やサポート窓口へ持ち越される。

廃止通知の送信数を成果にすると、この持ち越しが見えにくい。会社が欲しいのは大量の通知ではなく、旧製品に頼る仕事が減ることだ。伝えた事実と、変わった依存関係を別々に数える必要がある。

NuGet.orgの公開権限は所有者が持つ。パッケージの作者欄に名前があっても、それで管理権限が決まるわけではない。新しい所有者を追加し、相手が招待を受け入れ、その後で旧所有者を外す、という引き継ぎができる。招待中の状態では受け渡しは終わっていない。公開と所有者の管理

引き継ぎ資料を送っても、公開できる人が旧部署に残っていれば、次の更新で組織図を逆走することになる。権限を渡しても、なぜその互換処理が必要かを誰も覚えていなければ、今度は知識を探しに戻る。

個別企業の撤退費用を決めるには、実際の依存バージョン、サポートの約束、完了した移行の記録が必要だ。公式規則にはその顧客数も費用も載っていない。だからこそ、製品終了の承認資料にはカタログの状態と一緒に、まだ誰が何に頼っているかを載せたい。

倉庫に旧い部品が残ることは、顧客には安心になる。提供者には、残務を具体的に数える理由になる。看板を外す日に拍手するのは簡単だ。最後の顧客が道に迷わず出ていけるようにする仕事には、拍手より予算が要る。