Add design for simplifying workload versioning

[dsplaisted]

This proposal simplifies how workload versions are expressed and understood.

Currently, the design mainly covers the proposed changes to the user experience for workloads. That is the primary thing we are looking for feedback on now: Would this be a better user experience?

There will also be significant changes needed to implement this. Those still need to be written up and I plan to put those in a separate document, probably as part of this same pull request.

[dsplaisted]

The most common error message I see when workloads are broken for customers is something like: TargetPlatformIdentifier 'android' not found.

Usually what happened, is the WorkloadManifest.targets is missing for the android workload, and so the build did not understand the value for $(TargetPlatformIdentifier).

Will these changes be able to give a bit more information in this case? We might have an error message like "Workload Version 8.0.202 is not installed"?

Do you know why the workload manifest targets aren't installed in these cases? They should always be there.

The new design might be able to help with this but without understanding how people get into this state, it's hard to tell.

[jonathanpeppers]

I don't think anyone knows exactly how people are getting into this state. I think it is the combination of installing from VS and command-line, then some number of attempted upgrades/downgrades.

Usually the registry query + msiexec I mention here is what solves the problem:

https://gist.github.com/jonathanpeppers/63beb491a9185ac06710261536cc35c9#windows

[joeloff]

What are the rules around the versioning scheme inside the manifest? 4-part Windows version or a semantic version?