Repository navigation
Assert the winget PackageVersion, and write down what shipped wrong - #274
Merged
Merged
Conversation
#264 stopped the winget jobs passing the tag through as `PackageVersion`. This adds the assertion that should have caught it, and records the state of the catalog it left behind. The `Resolve PackageVersion` step now requires MAJOR.MINOR.PATCH and fails the job otherwise. `${TAG#v}` was already producing the right answer, so this is not belt-and-braces on the arithmetic -- it is the check that was missing entirely. winget-pkgs accepted `v0.2.2` through `v0.2.6` without complaint, so nothing downstream will catch a recurrence, and a merged manifest is permanent. The regex accepts every tag this repo has used plus a prerelease form, and rejects `v0.2.6`, `main` and `latest` -- the last two being what a `workflow_dispatch` re-run would have produced before #264. I also got the impact wrong when I first reported this, and the correction matters because it changes what needs doing. I said the mixed version set would affect `winget upgrade` ordering. It does not: winget normalises a leading `v` when comparing. Checked against the client rather than reasoned about -- > winget list --id fstubner.netscli netscli fstubner.netscli 0.2.0 v0.2.6 winget -- it offers v0.2.6 as an upgrade from an installed 0.2.0, and `--version 0.2.6` resolves `v0.2.6` while `--version 0.2.9` finds nothing, so the filter is real and the prefix is normalised. What is actually wrong is display: the catalog shows a version this project never issued, and the two packages sit inconsistently beside each other in `winget search` -- `v0.2.6` against the GUI's `0.2.6`. The next correctly-versioned release fixes that, since search and install use the latest version. docs/PUBLISHING.md records the catalog contents, the measurements above, and the one remaining decision: removing the five directories from microsoft/winget-pkgs is a PR against a third-party repo that breaks anyone pinned to those versions with `--version`, so it is deliberately not automated and doing nothing is a defensible answer. It also says not to reach for the action's `max-versions-to-keep` to prune them, because that deletes public catalog entries as a side effect of an ordinary release. All nine workflow files parse.
fstubner
changed the title
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.
#264 stopped the winget jobs passing the git tag straight through as
PackageVersion. This adds the assertion that should have caught it in the first place, and records the state of the catalog it left behind.I got the impact wrong, and the correction changes what needs doing
I reported that the mixed version set "will affect
winget upgradeordering". It does not. winget normalises a leadingvwhen comparing versions. Checked against the client rather than reasoned about:The filter is real and the prefix is normalised, so
0.3.1will compare correctly againstv0.2.6.What is actually wrong is display. The catalog shows a version this project never issued, and the two packages sit inconsistently beside each other:
The next correctly-versioned release fixes that, since
winget searchandwinget installuse the latest version.The guard
Resolve PackageVersionnow requiresMAJOR.MINOR.PATCHand fails the job otherwise.${TAG#v}was already producing the right answer, so this is not belt-and-braces on the arithmetic — it is the check that was missing entirely. winget-pkgs accepted all five bad versions without complaint, so nothing downstream will catch a recurrence, and a merged manifest is permanent.Tested against real inputs:
v0.3.1,v0.2.6,0.3.1,v1.0.0,v0.4.0-rc.1v0.2.6unstripped,main,latest, emptyThe last two are what a
workflow_dispatchre-run would have produced before #264 fixedrelease-tag.The decision I did not make for you
docs/PUBLISHING.mdnow records the catalog contents, the measurements above, and the one thing left open: removingmanifests/f/fstubner/netscli/v0.2.*/is a PR against microsoft/winget-pkgs, a third-party repo, and it breaks anyone pinned to one of those versions withwinget install --version. That is your call, not something to automate, and doing nothing is a defensible answer given the display self-corrects on the next release.It also says explicitly not to reach for the action's
max-versions-to-keepto prune them — that deletes public catalog entries as a side effect of an ordinary release, which is not something a release should do quietly.All nine workflow files parse.
actionlintis not installed here, so this is a parse check plus review, and the winget jobs cannot be exercised outside a real publish.