Open Trenly opened 2 years ago
Another related Issue https://github.com/microsoft/winget-cli/issues/910
I think I like where this is going. We've gone back and forth as to whether it should be one or many files. In some cases, we're only going to allow a verified developer to do things, so that metadata may only be modifiable by someone at Microsoft following official policy.
Having to check two places in the event there is a file at package level or version level can be complicated. We have avoided attempting to deal with conflicts as users might not know to look in multiple places. The Tombstone feature was the first to consider files at both locations.
The bigger the file gets in terms of scope, the more likely we could have a merge conflict, and we want to avoid that as much as possible. Maybe we can only allow only one PR to be open for one of these files at a time to help reduce this liklihood.
I think I like where this is going. We've gone back and forth as to whether it should be one or many files. In some cases, we're only going to allow a verified developer to do things, so that metadata may only be modifiable by someone at Microsoft following official policy.
Having to check two places in the event there is a file at package level or version level can be complicated. We have avoided attempting to deal with conflicts as users might not know to look in multiple places. The Tombstone feature was the first to consider files at both locations.
The bigger the file gets in terms of scope, the more likely we could have a merge conflict, and we want to avoid that as much as possible. Maybe we can only allow only one PR to be open for one of these files at a time to help reduce this liklihood.
That's true. The other thing we could do is to merge this concept with the .validation files; Something like -
Waivers:
- PackageVersion: 1.0.0
TestPlan: Validation-Domain
WaiverId: '{00000000-0000-0000-0000-000000000000}'
- PackageVersion: 1.0.2
TestPlan: Validation-Domain
WaiverId: '{00000000-0000-0000-0000-000000000000}'
Description of the new feature / enhancement
Much of these ideas rely on information on how to handle the manifest information, or to provide additional information that isn't intended to be in the package manifest. These ideas are currently suggesting individual Yaml files for their implementation. However, it should be possible to have all of this information in a single Yaml file and have an associated schema.
This would reduce any potential clutter from having files on how the application and other integrations would behave.
If included with a manifest submission, should be accepted by the pipelines. If the handlers contain only Tombstones and Maintaner-Users, community mods could be able to approve. If the handlers contain a redirect, robots handling, or Maintainer-Approvers, add a specific label and assign to a MSFT engineer for review
Proposed technical implementation details
A handler file could look something like this, and would be valid at the package or version level. If there is a handler at the version level and the package level, both should be considered, and any conflicts should be resolved by giving preference to the version level handlers.