docs: use unlikely example versions in nuget package script

[marcelwgn]

Summary of the Pull Request

The versions used here are not good examples for two reasons:

• The old version is higher than the new version
• They refered to actual versions meaning they would be picked up by the script

References

N/A

PR Checklist

• Closes #xxx
• CLA signed. If not, go over here and sign the CLA
• Tests added/passed
• Documentation updated. If checked, please file a pull request on our docs repo and link it here: #xxx
• Schema updated.
• I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: Remove workaround "When we add a new tab in compact mode, re-enforce Compact mode" #6681

Detailed Description of the Pull Request / Additional comments

Validation Steps Performed

[marcelwgn]

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.

[DHowett]

Funny thought: should the old version in the sed script be the one we currently have? That way, the script will always update "what we currently have" to [new value]?

(Feel free to merge w/o me)

[DHowett]

(Like: old would always be current, and new would never match anything so it would always look like a current->XXX transition)

[marcelwgn]

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.

[DHowett]

Perhaps the literal string new.package.version, which will have the added bonus of blowing up at compile time for anybody who doesn’t pay attention.

[marcelwgn]

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.