docs: correct the Pz.Cli/pz version boundary, and stop restating it - #5
Merged
Conversation
The rename PR wrote the boundary as 0.2.0 while v0.2.1 was still unreleased, so both notes predicted a number that then shipped under the old id. nuget.org has the truth: Pz.Cli published 0.1.0, 0.1.1, 0.1.2, 0.2.0, 0.2.1; pz published 0.2.2, the tag on the rename commit. The README's number was never the actionable part. A reader hitting that note already has Pz.Cli installed -- what they need is "remove it", not which release last carried the id -- so the note now names no version at all and cannot go stale again. It is also the copy embedded in every package at pack time, where a wrong version is wrong permanently. CONTRIBUTING keeps the numbers, because there they ARE the checklist item (which versions stay listed for lock-file restores), and says outright that the boundary is final. It cannot drift: the bullet it sits in forbids ever publishing under both ids, which is what froze it.
The five-command block is the first thing a stranger reads, and the note sat directly under it explaining a problem almost nobody reading it has: the old id only ever published 0.x, and nuget.org's deprecation already points `Pz.Cli` at `pz` in the gallery and in `dotnet`. The install line now runs straight into what the run prints. CONTRIBUTING keeps the boundary and the deprecation checklist, which is where whoever runs a release will look for it.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Drops the
Pz.Climigration note from the README, and corrects the version boundary where it still belongs.The bug it started from
The rename PR (#4) wrote the boundary as
0.2.0whilev0.2.1was still unreleased — so the notes named a version that then shipped under the old id. nuget.org has the truth:Pz.Cli0.1.0,0.1.1,0.1.2,0.2.0,0.2.1pz0.2.2(the tag on the rename commit,ca90edb)What changed
0.x, and nuget.org's deprecation already pointsPz.Cliatpzin the gallery and indotnet. The install line now runs straight into what the run prints.Why this isn't per-release maintenance
The boundary doesn't rot — it froze the moment
Pz.Cliwas deprecated, and the CONTRIBUTING bullet the numbers sit in is what freezes it ("do not publish new versions under both ids"). The original error was a one-off: a prediction written before the tag it predicted. CONTRIBUTING now says so outright, so no future release has to revisit it.Verification
dotnet build Pz.slnx -c Release— 0 warnings, 0 errors. Docs-only; no test pins either file.The
scripts/bundle/install.ps1legacy-uninstall behaviour is untouched — offline-bundle users still get the old tool-path install removed automatically, and the Windows how-to on the site still documents that.Site-side changes are in PipelineZ/pz-site#3.