Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Keep a Changelog

keepachangelog.com

Post reply on HN
Print view View original

11–20 of 53 posts

Re: Keep a Changelog

#11

Post by rezonant »

petethepig wrote: post #9

Semantic pull requests [0] + conventional-changelog [1] + squashing PRs and you get almost the same results (and more) with great automation and self-documentation for the whole process: * you'll never forget to add something to changelog * you get links to PRs in your changelog * it's much faster to make edits to PR messages compared to editing files * outside contributors get familiarized with the practice much fas…

Seconded, I've seen semantic PR plus squash add a lot of value both for the engineering side and the product side.

We do this and it works great, but I've still found value in summarizing things in a digest (ie changelog or release notes, depending on the context)

Re: Keep a Changelog

#12

Post by jopsen »

bromuro wrote: post #2

> Using commit log diffs as changelogs is a bad idea: they're full of noise. Things like merge commits, commits with obscure titles, documentation changes, etc. I’d rather fix that. I’ve been following the suggestion from this website in the past. It is a nice take but tedious and boring. Better have commit messages. For example: https://www.conventionalcommits.org

I think I've often seen a feature land, followed by 2-3 small PRs fixing corner cases discovered during dev-release testing. Or you agree to land a PR with some aspects left to be fixed in follow up PRs.

Typically, when projects are non-trivial in size, providing a changelog summarizing the important changes is useful.

Re: Keep a Changelog

#14

Post by gitgud »

rp1 wrote: post #6

Or you could just filter the commit history and use squash instead of merge.

That's better than nothing, but code commits and changelogs have different use cases.

Commit logs are for all changes, regardless of size or context. Whereas changelogs are for consumer-facing changes.

Re: Keep a Changelog

#15

Post by busbus »

petethepig wrote: post #9

Semantic pull requests [0] + conventional-changelog [1] + squashing PRs and you get almost the same results (and more) with great automation and self-documentation for the whole process: * you'll never forget to add something to changelog * you get links to PRs in your changelog * it's much faster to make edits to PR messages compared to editing files * outside contributors get familiarized with the practice much fas…

May I ask you why you want to squash every branch ?

What is the size of the resulting commit (in terms of average modified files, lines of code) ?

Re: Keep a Changelog

#16

Post by sjtindell »

rezonant wrote: post #11
petethepig wrote: post #9

Semantic pull requests [0] + conventional-changelog [1] + squashing PRs and you get almost the same results (and more) with great automation and self-documentation for the whole process: * you'll never forget to add something to changelog * you get links to PRs in your changelog * it's much faster to make edits to PR messages compared to editing files * outside contributors get familiarized with the practice much fas…

Seconded, I've seen semantic PR plus squash add a lot of value both for the engineering side and the product side. We do this and it works great, but I've still found value in summarizing things in a digest (ie changelog or release notes, depending on the context)

Thirded? Tertiaried? This is something I always beat myself up for not doing consistently. Automating it at a minimum checks the box, and also can provide real value.

Re: Keep a Changelog

#17

Post by ReleaseCandidat »

petethepig wrote: post #9

Semantic pull requests [0] + conventional-changelog [1] + squashing PRs and you get almost the same results (and more) with great automation and self-documentation for the whole process: * you'll never forget to add something to changelog * you get links to PRs in your changelog * it's much faster to make edits to PR messages compared to editing files * outside contributors get familiarized with the practice much fas…

It always depends on your users. Such a changelog is suitable for stuff other developers use, but not for end users.

But it is a _way_ better starting point to write a changelog that 'usual' commit messages or PR descriptions.

Re: Keep a Changelog

#18

Post by jayflux »

GitHub have developed a feature to generate release notes based off the commit history, might be worth trying. You can configure it to filter out users, group by labels etc https://docs.github.com/en/repositories/releasing-projects-o...

For those saying “just use commit history”, I once had to sift through 200 commits because the library author was too lazy to separate the breaking changes from the patches. It’s horrible for users of your library, a changelog doesn’t have to replicate your commit log but it should at the least be the “highlights” or need-to-know version of it.

Re: Keep a Changelog

#20

Post by majkinetor »

ReleaseCandidat wrote: post #17
petethepig wrote: post #9

Semantic pull requests [0] + conventional-changelog [1] + squashing PRs and you get almost the same results (and more) with great automation and self-documentation for the whole process: * you'll never forget to add something to changelog * you get links to PRs in your changelog * it's much faster to make edits to PR messages compared to editing files * outside contributors get familiarized with the practice much fas…

It always depends on your users. Such a changelog is suitable for stuff other developers use, but not for end users. But it is a _way_ better starting point to write a changelog that 'usual' commit messages or PR descriptions.

I disagree. I publish to the end users and they are grateful all the time.

I use custom scheme tho, using Gitlab issue title and issue labels. I find this more meaningful since one issue can contain multiple PRs and I still want single changelog line.

Post reply on HN