Repository navigation
Include release date as optional metadata in manifests #873
Description
I propose to add an optional metadata field to the manifests to store the date of when the version of the software was released (not when the manifest was written/last updated, although that might also be interesting and could even be derived automatically from git history). I think the version release date would sometimes be very useful (and IMO certainly more useful than some of the other information that winget show currently displays).
Why do I think that release dates are interesting?
Suppose you found some app via a tag search through winget search that you don't know yet. From the version number alone that winget show displays, it is not apparent whether this is an app that is still actively maintained or whether it was last updated years ago. This information can be a deciding factor whether to install an application or look for an alternative instead.
Some potential hurdles:
- It might not always be possible to find out the release date of a version as it is sometimes simply not documented on the publisher website. That's why the metadata should be optional.
- Some applications have static installers that rarely get updated and where the app self-updates after the first start (this is the case for JDownloader, for example). In this case, it might be confusing for users or manifest writers what the release date in the manifest means. On the other hand, you may argue that in this case we already have the same problem with the version number in the manifest which does not reflect the latest version number that users end-up with when they start the app, so it is probably not really a new issue.
Activity
jedieaston commentedon Apr 15, 2021
This would also be useful for tracking when a package manifest with
PackageVersion: latestis updated, since at the moment you can kind of figure it out via seeing when the hash changes ingit log, but it's a real pain and not accessible to the end user.chausner commentedon Apr 15, 2021
The list of versions displayed by
winget show --versionscould be made more useful by also showing the release date of each version.denelon commentedon Apr 15, 2021
I'd be open to adding an optional release date field. We would need to lock on the date format so it's consistent across packages. It's also something that essentially could change with any PR, but that's the world we live in, so I think the risk is fairly low.
I like the suggestion regarding
winget show --versions.We have a few new fields likely coming over the next few months to support a better store source and experience. The hope is that it's a non-breaking change with a new v1.1.0 manifest schema. The 1.0 clients could essentially ignore the new fields, but the 1.1 capable clients would be able to render the meta-data. That would be an ideal time to include any new fields.
chausner commentedon Apr 21, 2021
Shall I go ahead and draft a spec for this or would you rather bundle this with the other additional planned fields that you mentioned?
denelon commentedon Apr 21, 2021
chausner this would need a spec since changes to the schema have a large surface area for the project. Our validation pipelines, the HTTP REST API, and the nuget package we use to share these kinds of things would all need to be updated. We would also need a minor version bump on the schemas. Depending on your rate of progress, I can add some of the other fields into the spec and we can see about getting the new fields bundled together.
denelon commentedon Jul 1, 2021
This field goes in the installer node as installers are released on different dates in some cases.
The value would be displayed under Installers: in
winget showValidation Considerations
"February 31st, 2021" <- Not Valid
If date >Today <- Not Valid
if date <1970-01-01 <- Not Valid
denelon commentedon Oct 1, 2021
winget-cli/schemas/JSON/manifests/v1.1.0/manifest.installer.1.1.0.json
Lines 358 to 362 in 5a97e26