[New Feature]: Have Wingetbot try to match the version formatting

[Trenly]

Description of the new feature/enhancement

This idea is based from these PR's, among others:

• Automatic update of Tutanota.Tutanota from 3.89.9 to 3.89.12.1805 #34417
• Automatic update of NordPassTeam.NordPass from 4.12.23 to 4.13.19.21804 #34404
• Automatic update of VB-Audio.Voicemeeter.Potato from 3.0.1.8 to 3. 0. 2. 1 #34055

I propose that @wingetbot should try to pattern match whatever version it detects to the package version which already exists in the repo. This would allow the bot to be self-correcting in the cases where the tag or published version is of a different string format than the one in ARP.

This may also be something to consider along with microsoft/winget-create#203

Proposed technical implementation details (optional)

I know it would take a lot of work, but it should be possible to do string interpolation like this. Alternatively, if the bot had an environment to install the application and pull directly from ARP, that would avoid the issue entirely.

Examples:

Found Version	Previous Version	Version to use
3.89.12.1805	3.89.9	3.89.12
4.13.19.21804	4.12.23	4.13.19
2020-12-5-1388	20.11.15.1182	20.12.5.1388

[jedieaston]

I've suggested before in an old discussion that the validation pipeline should be able to verify the ARP metadata, and I believe @denelon said they were investigating it (so that getting the data for microsoft/winget-cli#1073 would be entirely automated). I don't know if any more thought has gone into that, but it could help with the latter part of your request.

[denelon]

We are getting much closer to being able to do this. Internally another team is also working on validation in the Microsoft Store validation flow. We're going to augment their functionality to include support for our scenarios. We will be switching to that validation service and retiring the one we built after we have full parity. It doesn't make sense to have two teams working to solve the same problems. We are hoping it will give us more capacity to continue developing more new features and fixing more bugs. I don't have an ETA for this yet as we're still in the discovery and design phases. It will most likely be a transparent change to the community. We have already included validating "Apps & Features" data in the manifest against what was detected in the validation VM. It will also likely mean the bot will need to be able to submit a subsequent push to the branch it is working on when it creates an initial PR to update the metadata.

[jedieaston]

Does this kill the discussion about some of the validation code being open-sourced? (Not the end of the world if it's going to be easier to maintain for you going forward, but it'd be nice to help 😊).

[denelon]

We're still hoping to open source some of the validation code. The parts that we aren't able to be open source will at least be documented in a way to help understand what check was performed, and the various failure reasons. We had a long arduous path to develop the policies and at least get those specific errors called out. We're hoping to be able to get more granular where we can, and at least make it a bit more transparent. We still suffer from some services that we still must treat as a closed system ourselves. We don't always get informed why something failed, just that it did. Some of those have also been false positives and false negatives which makes things much harder to troubleshoot and be transparent about.

[vedantmgoyal9]

@denelon Area-Bots These issues are related to the bots assisting with automation