You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Current changelog is basically for nobody except core developers. Information about useful features for end users is suffocated by developer issues noise.
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.
Miodrag Milić (@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).
Activity
denelon commentedon Mar 18, 2025
Miodrag Milić (@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).