Questions regarding returning to contribute

[superusercode]

Is it preferred to use the version manifest type now? Should I migrate all my existing ones to it? Are there any quirks I should be aware of when transitioning my packages to use the new manifest type and away from singleton?

Additionally, is it possible to provide fixed versions of manifests alongside one that auto updates (i.e. set to latest)? Is wingetbot actively checking the version types on the manifest file(s) or does it make assumptions on the increments? For the few hosts that do keep previous versions on the same url (sourceforge, github, etc.) is there a way to have wingetbot preserve those previous versions and just act like how scoop/chocolatey do auto-updates?

I'm a college student, so ideally I'd like to set up all my manifests in a manner that has them auto update. I still prefer the method that scoop uses since it allows for more auto update sources. Getting it to a point where user bots is no longer necessary would be ideal, since anyone trying to contribute additional info to those bot/user maintained manifests will promptly lose their changes.

Is productcode only used by programs installed via MSI? Does winget upgrade circumvent the limitation that MSI has with updating from one minor version to another? (https://stackoverflow.com/questions/38213149/how-to-make-an-msi-minor-upgrade-and-how-to-apply-it)

Do the installer types automatically include the known/expected good exit codes for their packaging? (i.e. nullsoft, inno, etc.)

[denelon]

Lots of good questions here.

If you move to the multi-file manifest, it is easier for additional locale meta-data files to be added without having to do the full conversion. It's really your preference 😄

Our current client logic (v0.3.z) treats "latest" as the latest version if a manifest with that version is specified (over explicitly versioned manifests). Older versions with explicit values are welcome. That provides a mechanism to retain access to older versions of a package. If an installer contains meta-data for explicit versions the automation does attempt to generate a versioned manifest. Generally we run into challenges when the URL is a "vanity" URL. If the installer changes at that URL, the hash-mismatch check will identify that manifest as being "invalid".

We've got an Issue to improve documentation for ProductCode. microsoft/winget-cli#921

We haven't automated anything to detect non-zero success error codes. They can be included in the manifest if known, but there are several edge cases that led us not to automate that yet.