Closed Den-dp closed 2 years ago
Sounds reasonable, that is a lot of release always in one go which could be skipped. @bbortt Do you have access to edit the releases?
We could setup release-drafter and collect all the changes. And then initiating a release manually.
I do understand, that it is very noisy. the reason I added it, is that it was very handy back then: it requires 0 manual interaction, and I didn't know about semantic-release
at this time.
I think I can give it some effort to replace standard-version
by semantic-release
. didn't have much time lately, because I am writing my thesis currently 😅 but that much I can invest.
it does a much bedder job at filtering relevant commits (ignores types chore
, ci
and sorts), hovewer. it would then release just code changes. does that sound good to you? see my personal project for reference..
@bbortt Do you have access to edit the releases?
yes, I do. however I would leave it as is, I think. and look forward to be less noisy in the future 🚀
I would like to raise an idea of how to improve Developer Experience of CHANGELOG.md and Releases overall.
I think that a new Release should be done only if the source code is changed or if a regular package
dependency
is updated (sofeat
,fix
,revert
,perf
).For all other changes, such as updating devDependencies, CI-related stuff, tests, docs, and code formatting (
ci
,chore
,docs
,style
,test
) there is no need to publish a new npm release.This should allow both CHANGELOG.md and Releases to be less noisy (cause there will be fewer releases) and more readable for the consumers of the package, whose job is to understand what has changed in the code they really touch/install (cause instead of one-line release logs there will be batched ones with both code changes (primary stuff) and chores around it (secondary)).