Auto-Updating manifest for new version/ meta-manifest

[JustMyGithub]

Description of the new feature/enhancement

As I understand Winget, an update of an application causes the need for the community to create a new manifest. As many (probably most) public manifests do only reference official setup files (and are not "silent" re-packages) There should be a way for a more generic definition that does not rely on a quick response of a maintainer (and maybe also the winget team to accept a PR)

Proposed technical implementation details (optional)

Define (in the manifest or in some kind of meta-manifest) where the official information about version (and maybe download url) can be retrieved. This means to provide an url and a location within the file referenced by the url. The location within the file can be defined by several techniques, including StringBetween (define the text before and after the Information), XPath (as most sources will be html files) or RegEx.

The repository server checks for updates every 24h or so and updates the the manifest if changes are detected (checksum, download url, version number).

[LeonarddeR]

I think this would be very helpful, especially for nightly/insider/alpha version of software.

[denelon]

We already have automation for determining if a manifest is no longer functioning due to hash-mismatch or a URL that is no longer valid. This seems like a request to have the community repository or some automation associated with it to see if a new version of a package is available. This may be closed in the future as a duplicate as that request has been made before.

[JustMyGithub]

That depends on the feature request that you did not reference to.

[denelon]

Here is one of the examples: #1184

[vedantmgoyal9]

Related or Duplicate of: #500 #1184 #1515

[vedantmgoyal9]

@denelon Can we close this and #1184 as they will be covered in #500.

[denelon]

@vedantmgoyal2009 this one is looking more like the issue we will use to track adding metadata to the .package file once we have had a chance to flesh the design out more. We want to cover not only GitHub release, but also things with an RSS feed and potentially other mechanisms for determining when a new version is available and where we could programmatically check.