docs: use unlikely example versions in nuget package script#7448
docs: use unlikely example versions in nuget package script#7448DHowett merged 2 commits intomicrosoft:masterfrom marcelwgn:dev/chingucoding/update-nuget-doc
Conversation
| Example usage: | ||
|
|
||
| `git grep -z -l Microsoft.UI.Xaml | xargs -0 sed -i -e 's/2.5.0-prerelease.200609001/2.4.200117003-prerelease/g'` | ||
| `git grep -z -l Microsoft.UI.Xaml | xargs -0 sed -i -e 's/2.4.0-prerelease.200506002/2.5.0-prerelease.200812002/g'` |
There was a problem hiding this comment.
Those versions don't refer to actual packages because the first two digits are the year, the second two digits are month, and the next two digits are the day. By changing the last digit, we are actually referencing the second package of that day which will not exist, thus wouldn't be a valid upgrade/downgrade path. This avoids people accidently changing the values while updating the WinUI version.
|
Funny thought: should the old version in the (Feel free to merge w/o me) |
|
(Like: old would always be current, and new would never match anything so it would always look like a current->XXX transition) |
|
I like that idea, though I see one big problem: How do we ensure that the new version is higher then the old version? Any version we chose will get outtadet at some point. And when that happens we are essentially back to the current state where the old version is higher then the new version, which is confusing when reading the example. |
|
Perhaps the literal string |
|
Hmm. But replacing $NewVersionNumber with "new.package.version" or something similar for an example isn't too helpful I think. But if the team desires that, I will change that. |
DHowett
changed the title
4 participants
Summary of the Pull Request
The versions used here are not good examples for two reasons:
References
N/A
PR Checklist
Detailed Description of the Pull Request / Additional comments
Validation Steps Performed