Global tool package ID rename stranded 10.3.x consumers on Fallout.GlobalTool with no upgrade path #575

Problem

The dotnet-tool package ID changed from Fallout.GlobalTool to Fallout.GlobalTools in f0208100. The old ID was left published, listed, and not deprecated, so consumers pinning it cannot reach 10.4 and get no signal that a successor exists.

Published state on nuget.org:

A real consumer manifest (Chrison-dev/Krautwatch):

"fallout.globaltool": { "version": "10.3.49", "rollForward": true }

That pin is already at its ID's ceiling. 10.4.0-rc.4 exists only under fallout.globaltool s. rollForward resolves within a single package ID, so it cannot cross to a different one. dotnet tool update and dotnet tool restore can never reach 10.4 from this manifest.

The failure is silent and misdiagnoses. nuget.org correctly reports 10.3.49 as the latest for Fallout.GlobalTool, so the natural reading is "10.4 is not published yet" rather than "it was renamed". That is the wrong conclusion, and it is the one a consumer reaches.

Why it shipped unflagged

f0208100 assessed the rename as Fallout.Cli → Fallout.GlobalTools and concluded:

"Fallout.Cli was never pushed to nuget.org, so this is a pre-publication rename — non-breaking."

Fallout.Cli had in fact been published (10.3.39–10.3.47, 11.0.x). More importantly, the ID that 10.3.x consumers actually pinned was Fallout.GlobalTool, which the assessment never considered. The break was measured against a package nobody was using.

Why the canary did not catch it

Fallout.Canary consumes the framework packages via PackageReference and runs dotnet run --project build/_build.csproj. It has no .config/dotnet-tools.json and never runs dotnet tool install or dotnet tool restore, so the tool package identity is outside its coverage. Its nuget.config already maps fallout.globaltools to a source, but no scenario exercises it.

Outcome

An existing consumer on any retired tool ID learns about the rename from the tooling itself, and fallout-migrate moves their manifest to a manifest that restores.

Acceptance criteria

• Fallout.GlobalTool is deprecated on nuget.org with Fallout.GlobalTools as the alternate package
• fallout-migrate rewrites dotnet-tools.json tool IDs (nuke.globaltool, fallout.globaltool, fallout.cli) to fallout.globaltools
• The rewrite re-pins the version to one that exists under the new ID — renaming the key alone produces a manifest that fails dotnet tool restore
• Docs name one install ID consistently; docs/introduction.md currently says Fallout.GlobalTool on line 21 and Fallout.GlobalTools on line 48
• This repo's own .config/dotnet-tools.json stops pinning fallout.cli 10.3.45, which is an unlisted version of a retired ID
• Fallout.Canary has a scenario that restores the tool from a manifest, so a future tool-ID change fails loudly

Notes

The nuget.org deprecation is the highest-leverage item: it reaches every existing consumer without them reading docs or running the migrator. The other items only help people who do one of those things. It is a publishing action, so it cannot ride a PR.

fallout.globaltools has no stable release — only 10.4.0-rc.4. Until a stable one ships, the migrator can only re-pin to a prerelease.

Rule #1 in AGENTS.md requires a CHANGELOG.md entry for a breaking change. There is no CHANGELOG.md in this repo, so that rule is currently unfollowable and needs a separate decision.