Closed maennchen closed 1 year ago
Totals | |
---|---|
Change from base Build 6cf039f7272df5d23f69b89b4da4f54128e9fd1d: | 0.0% |
Covered Lines: | 325 |
Relevant Lines: | 325 |
@maennchen we generally avoid GitHub releases for Elixir libraries since they don't add much, given we already have the changelog as well as Hex releases. I’m thinking maybe we can get rid of this whole thing?
@whatyouhide The changelog is currently in the GitHub releases and there’s no file.
I personally find it a lot cleaner than having a changelog file.
GitHub releases also offer better integrations into tools like renovate bot that will automatically show the release notes for the updates.
I would therefore like to stay with this approach.
Is there disadvantages that I‘m overlooking?
The fact that most other libraries we maintain use a CHANGELOG, which feels like the expected thing at this point. Can we move to a CHANGELOG, and then potentially discuss GitHub releases across more libraries?
@whatyouhide We can for sure have a more generalized discussion.
Which other libraries are you referencing? Just gettext or also other ones?
All libraries that I know of under https://github.com/elixir-lang, and Elixir itself.
@whatyouhide The elixir language itself& ex_doc use both GitHub releases and a file based changelog.
gen_stage and elixir_make only use a file based changelog.
Currently not even inside the elixir core organisation all parts have the same setup.
Can we do it this way until a standards-discussion has come to a conclusion?
At the same time I would open a mailing list thread discussing a standardized way.
As soon as a conclusion is reached, we will make sure all libraries including this one are in conformance.
Let's close this PR, and use a CHANGELOG file for this repo too please, with the changes in the file. No changelog in the GitHub releases.
Also, Elixir uses GitHub releases for the releases, but there are no release notes attached to that, since the notes are in the CHANGELOG.
To be clear, I think these release notes are not useful:
Listing all commits is something folks can just do by going to the commits 🙃 The point of release notes (that is, a CHANGELOG) is to edit those notes in order to highlight interesting and relevant changes.
@whatyouhide I honestly believe that file based is the worse option.
If we change a working setup to something else, I would at least like to understand the reason for it which I currently don’t.
I‘m not arguing that the description of the release itself couldn’t be better. The autogenerated ones are helpful to with writing good notes by hand. I‘m only arguing that the releases page is an important place to put the changelog notes.
Consistency is the reason. A CHANGELOG-file-based approach has the same information as GitHub releases, but is consistent with the rest of our repositories.
@whatyouhide Please make sure to fix the link to the changelog file in the mix.exs.
I would like to at least be consistent with ex_docs. => Changelog entry copied into releases.
This is so that tooling that provides updates will cleanly show the release notes.
I will open a mailing list thread in the elixir mailing list so that all official libraries can be consistent themselves.
This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.
Totals | |
---|---|
Change from base Build 6cf039f7272df5d23f69b89b4da4f54128e9fd1d: | 0.0% |
Covered Lines: | 325 |
Relevant Lines: | 325 |
This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.
Totals | |
---|---|
Change from base Build 6cf039f7272df5d23f69b89b4da4f54128e9fd1d: | 0.0% |
Covered Lines: | 325 |
Relevant Lines: | 325 |
Automatically generates the notes for a release as they are now. (Can be overridden to add more information)
Reason: Saw that we forgot to publish the latest release. It was still in draft state.