search

typelevel / typelevel.g8

A typelevel.g8 based on sbt-typelevel
https://typelevel.org/sbt-typelevel/
14 stars 5 forks source link

Consider adding a CHANGELOG boilerplate #25

Open DavidGregory084 opened 2 years ago

DavidGregory084 commented 2 years ago

I've used the Keep a changelog format in a few projects now and I'm a fan of it, perhaps we could add this to typelevel.g8 as well?

rossabaker commented 2 years ago

From experience, it's a burden to maintain a changelog in addition to GitHub releases. This is a shame, because GitHub releases are not part of the git history, not portable, and therefore Are Considered Harmful

In olden times, there was a convention of release notes in a notes/ directory that were read by an sbt plugin and published to a Tumblr called implicit.ly, but kept a record in git. It was great. I think there's a missing SBT plugin that concatenates our GitHub releases into a portable, versioned CHANGELOG... or, alternatively, creates GitHub releases from notes in Git.

armanbilge commented 2 years ago

I'm lazy to keep a changelog, but I have to say another advantage is that they synthesize a PR that other maintainers can review/edit/contribute to. This process has been helpful for large projects like http4s.

DavidGregory084 commented 1 year ago

Spotted this completely different approach to managing versions and changelogs a couple weeks ago - the CHANGELOG.md file drives everything. IMO it's a bit of a pain to use Markdown for this and it leads to merge conflicts in the "Unreleased" section every time a PR is merged, but the idea could be interesting if it used a more structured format.