Increase number of Tags allowed for 1.12 manifests

[Trenly]

• I have signed the Contributor License Agreement.
• I have updated the Release Notes.
• This pull request is related to an issue.
  • Resolves Increase the number of allowed tags from 16 to many more in Manifest 1.12 #5783

---

Microsoft Reviewers: Open in CodeFlow

[dkbennett]

A few points here:

1. It is very late in the release for a schema change, so this should go into 1.13 after 1.12 is released.

2. Unsure what sort of impact on the UI or index if someone were to actually have 64 tags.

3. We would want a test case for that and to update the manifest schema sample to include an entry with preferably 64 tags of respectable size (perhaps find some long words to use) to verify the behavior actually works and that tag size doesn't cause any issues downstream or when enumerated.

4. A final point - should manifests have that many tags? A smaller size means people might be more concise and judicious with their tag usage, while a large number would allow tag spam to increase discoverability and might be a net negative to the product.

Putting a "request changes" specifically for the tests on the manifests. If we just wait the 'latest' will be come 1.13 (I'm doing this for some other changes with uninstall switches). Also for folks like @denelon and @JohnMcPMS to weigh in on whether tag count increase is a good thing.

[denelon]

@DandelionSprout do you have a "good" example where more than 16 makes sense and isn't just spamming for more hits?

[Trenly]

As far as I can see, the UI and index creation tools will handle an increase seamlessly - they are already abstracted to simply iterate through the collection of tags. The only item I see would be a potential increase in index size as more tags are added.

Additionally, I don’t see how any additional tests beyond what is currently in the codebase would provide benefit. The current tests make sure that the tags field (at least up to a few tags) gets populated and retrieved correctly. In my opinion this is actually an extremely minor change, with almost no technical risk. The length of a single tag is something that, if it were an issue, would be an issue in the existing code anyways; and the only places tags are consumed are 1) building and searching sources, and 2) Showing a manifest. The winget show would be uneffected as that simply iterates over the tags parsed from the manifest and sends them to the output stream - if this was effected I would anticipate the currrent tests for parsing manifests would catch it. Similarly, building and searching the index should be uneffected, as the underlying logic is not changing.

Perhaps I could add a manifest into TestData with a large number of tags to be certain the test index will build successfully, but I don't see what other tests would cover areas that aren’t already tested

[DandelionSprout]

@denelon

• https://github.com/microsoft/winget-pkgs/blob/master/manifests/a/AOMEI/PartitionAssistant/10.9.0/AOMEI.PartitionAssistant.locale.en-US.yaml (A lot of its programs-within-a-program are not properly tag-covered by names or functions)
• https://github.com/microsoft/winget-pkgs/blob/master/manifests/e/EpicGames/EpicGamesLauncher/1.3.155.0/EpicGames.EpicGamesLauncher.locale.en-US.yaml (Lacks space for fairly important tags like egs in particular)
• https://github.com/microsoft/winget-pkgs/blob/master/manifests/a/ares-emulator/ares/146/ares-emulator.ares.locale.en-US.yaml (It supports around 10 additional systems that couldn't be fit into the tags)
• https://github.com/microsoft/winget-pkgs/blob/master/manifests/d/DiskInternals/LinuxReader/4.24.1/DiskInternals.LinuxReader.locale.en-US.yaml

[denelon]

And... I just thought about PowerToys which has nearly 30 utilities.

[Trenly]

I'm going to mark this as a draft until the manifest schema version is bumped