Better changelog

[majkinetor]

Description of the new feature / enhancement

Current changelog is basically for nobody except core developers. Information about useful features for end users is suffocated by developer issues noise.

In Windows Package Manager 1.11.180-preview we have lots of these:

• Update Newtonsoft.Json to be same version across all projects
• For truly async calls we must maintain our lifetime
• Update primary index when moving package
• Add developer guidance for debugging & running tests
• Don't let unset error codes be thrown
• Fix logging channel setting
• Add support for 1.10 manifest in rest source parsing and winget utils interop

While for end user, only 1 is relevant:

• Experimental support for DSC v3

That one is mentioned both in new features and in all features but in general I do not find it consistent across releases.

As this kind of changelog defeats the main purpose of it - communication to end users, I strongly suggest putting development stuff to its own section and concrete feature and enhancements before it and perhaps use labels that changelog bot will use to know which goes where.

Proposed technical implementation details

No response

[denelon]

@majkinetor, thanks for sharing the feedback. We've been going through several changes to further automate our releases to enable getting more frequent releases out. Generally speaking, we take more time to have "customer" facing summaries for release candidates or stable releases like WinGet 1.10.320.

In the case of a "preview" build, the changes might only be partial implementations, or work behind some kind of feature toggle, or a minor bug fix. The content under "What's Changed" is essentially automatically generated by GitHub and is linked to PRs (Pull Requests) written by the developer implementing some code change.

The content under "New Features" is written out manually as a summary of what's included. In this case, there are several related features for this preview, and it's not a complete implementation. This is work being done on an experimental feature.

The release notes and associated links to PRs are intended to help folks who are contributing to the project at GitHub or folks who are trying to identify whether or not an Issue has been implemented and could possibly be tested. The content for "public" or "end users" is primarily maintained at Microsoft Learn. The majority of "help" content in the product also includes links to content at Microsoft Learn (with the exception of experimental features).