VerifyTests
GitHub releases and/or a CHANGELOG
Is the feature request related to a problem
When automated pull requests from dependabot or Renovate come into repositories for Verify's NuGet packages, there are no signals to the user as to why there is a new release (example).
This means the user needs to manually review the diff to see what's been changed.
In the case of 30.4.0 to 30.5.0, the diff is quite large (50 commits, 304 files changed).
With GitHub releases and/or a CHANGELOG, automated dependency tooling can summarise changes in the pull request description for the user (example) without them needing to do this themselves.
Describe the solution
Produce GitHub releases with release notes and/or a CHANGELOG that users can read to get a summary of what's changed.
GitHub releases can be created with a summary of what's been changed automatically populated from the commit messages, provided that they containing meaningful content as to what's being changed.
Describe alternatives considered
None.
Additional context
The lack of release notes and a release for [email protected] was one of the contributing factors which lead me to realise the package had been compromised: https://github.com/prettier/eslint-config-prettier/issues/339
Having either contributes to the provenance of a given release being legitimate.
https://www.npmjs.com/package/eslint-config-prettier/v/10.1.8
Is 10.1.8 good to use ?
@martincostello this project uses milestones for release notes https://github.com/VerifyTests/Verify/milestones?state=closed
That doesn't solve the issue of automated dependency apps not giving the user a view in the PR of what was changed though.
i am happy to consider a pull request that creates GH release notes when a GH milestone is closed, or a closed one is modified
Here's an example of automated GitHub release creation that I use for my own repos you can use for inspiration: code.
My workflow is different though - I run that workflow when I want to cut a release, it then creates a draft GitHub release which I manually check (and tweak the release notes if necessary), then publish. That creates the tag, which kicks off the CI to build and publish, and then other automation closes the related milestone.
Given your workflow is different, and this would need applying to however many different repositories Verify is split over, I think it's best done by yourself (or some other member of the VerifyTest organization) rather than me trying to work out how to fit it into your existing process.
or some other member of the VerifyTest organization
yeah, its just me.
i will try to get to it