Move as many parameters as possible to Manifest Level

[Trenly]

Description of the new feature/enhancement

Currently the installer type, scope, upgrade behavior, etc. are always placed at the Installer Level. When these values are the same for all installers, they can be moved to the Manifest Level

Proposed technical implementation details (optional)

Any parameters which are the same across all installers and are valid at both the manifest level and the installer level should be moved to the manifest level during creation or update

[jedieaston]

I wonder if this should be enforced in a hypothetical schema 2.0. There aren't a ton of circumstances where putting InstallerType or others globally doesn't just turn into a headache later when you want to add a new installer entry.

[Trenly]

I wonder if this should be enforced in a hypothetical schema 2.0. There aren't a ton of circumstances where putting InstallerType or others globally doesn't just turn into a headache later when you want to add a new installer entry.

I think that is an interesting point. I think this is mostly a concern when you manually modify the installer entries for new manifests. If you use a tool or a script like the YamlCreate script, then it should handle it automatically. It certainly is something to consider as to whether or not this would be a good thing

[denelon]

We've had some discussions around this with the feature team. Some of the optimizations like the singleton format and "root" level nodes that can be overridden in a child node were mostly made for humans crafting manifests. As we're getting closer to solid tooling support, these may be deprecated in favor of a tool generated manifest. It would certainly be a breaking change so the 2.0 schema was a good call out by @jedieaston.

[mdanish-kh]

• Resolved in Shift common installer fields to manifest root level #409

[mdanish-kh]

The fix (PR #409) is available now in WinGet-Create 1.5.1.0

cc @denelon / @Trenly if this can be marked as completed