That sounds neat, but I *personally* have a problem with conventional commits. For those not familiar, the format is basically
``` <type>[optional scope]: <description> [optional body] [optional footer(s)] ``` The width of the title line of a commit is supposed to be ~52 characters, but `feat(scope): ` eats up 13 of those characters, meaning that the subject can’t exceed 39 characters. Even if you skip scopes, you’ve lost a minimum of five characters for a commit title line (`bug: `). I know that not everyone writes good commit messages (tpope and Chris Beams have excellent blog posts on these), but using the *title* line to help a program do something useful is the very definition of Doing The Wrong Thing. I’d support a *trailer* / *footer* like `commit-type: feat!` (feature with breaking change), but I’m already involved with one project that uses conventional commits and I hate writing commits there, because the title should be short but meaningful, and that’s hard in 52 characters. -a (Sorry. I’ve not really had a place to rant about this because I stopped blogging years ago, I’ve given up on Twitter, have no Mastodon presence, and no one on Facebook would care.) On Fri, Jan 13, 2023 at 9:31 AM Zach Daniel <zachary.s.dan...@gmail.com> wrote: > My library git_ops https://github.com/zachdaniel/git_ops is a native > elixir solution for managing a change log with tags for releases. Im sure > it could be improved, but it’s a solid foundation that a lot of people are > using today. Plus, the conventional commit format is a well known already > specified pattern: https://www.conventionalcommits.org/en/v1.0.0/ > > It provides a mix task that automatically determines the next version > based on the types of commits, and writes any relevant commits to a > changelog file. > > In standardizing the changelog practices, you could also standardize the > commit/next version practices. > > > On Fri, Jan 13 2023 at 6:28 AM, Jonatan Männchen <jona...@maennchen.ch> > wrote: > >> Hi Everyone, >> >> I had a discussion with Andrea (@whatyouhide) about how to handle >> changelogs in elixir itself as well as core libraries.The way how those >> libraries implement changelogs is important both to auto-discovery of >> changes with auto updating tools like renovate and also because it is a >> place for guidance / inspiration for independent library creators. >> >> This proposal is only about the mechanism of publishing changelogs. It is >> not about the contents. >> >> *Current state:* >> >> - Core >> - Elixir >> - per minor release: CHANGELOG.md file >> - GitHub release is automatically created >> - Artifacts are stored in release >> - manual copy of text into GitHub release >> - ExDoc >> - global CHANGELOG.md file >> - manual copy of entry into GitHub releases >> - GenStage >> - global CHANGELOG.md file >> - no GitHub releases >> - ElixirMake >> - global CHANGELOG.md file >> - no GitHub releases >> - Phoenix >> - per minor release CHANGELOG.md >> - some GitHub releases were created, not up-to-date >> - Tzdata >> - global CHANGELOG.md >> - no GitHub releases >> - Jason >> - global CHANGELOG.md >> - manual GitHub releases >> - Plug Cowboy >> - per major version CHANGELOG.md >> - manual GitHub releases >> - Telemetry >> - global CHANGELOG.md >> - outdated GitHub releases >> >> >> *Possibilities for standardization: *(i can think of, reply with others >> if you think something is missing) >> >> >> - Only CHANGELOG.md >> - Changelogs are written by hand and not published via GitHub >> releases >> - Drawbacks >> - Hard to automatically discover changes (for example Renovate >> Bot) >> - not as well integrated in GitHub itself as GitHub releases >> - does not support extra artifacts like binaries >> - Advantage >> - simple >> - no extra manual labor >> - CHANGELOG.md + GitHub releases manual copy >> - On release the CHANGELOG.md file is extended with no >> information. After the release the notes are copied over into a new >> GitHub >> release manually. >> - Drawbacks >> - Needs extra manual labor >> - Entries can be missing because people forgot to do it >> - CHANGELOG.md & Automated GitHub release note >> - On release the CHANGELOG.md file is extended and a GitHub >> workflow will parse the CHANGELOG.md and use the text to create a >> release. >> - Drawbacks >> - Introduces some complexity & maintenance by adding CI >> workflows >> - GitHub releases & automatic appending of CHANGELOG.md file with >> release notes >> - To release a person would create a GitHub release and a workflow >> would automatically prepend the changes to the CHANGELOG.md file >> - Drawbacks >> - Same as the option before >> - Workflow is more complicated because it would need to commit >> code by itself >> - Imposes a more rigid process on the release workflow while >> other options are more flexible. >> - Only GitHub releases >> - Changes are only published via GitHub releases >> - Drawbacks >> - not portable if the community ever migrates away from GitHub >> - the CHANGELOG.md file does either not exist in published >> libraries or would need to be generated on demand out of the >> releases >> >> *My personal favorite solution so far:* >> >> CHANGELOG.md & Automated GitHub release note >> >> The reason for that preference is that it is relatively easy to automate >> and that it offers the best if both worlds. >> >> *Implementation* >> >> I’m happy to provide a shared action as well as PRs for all core >> libraries. >> >> Such a shared action could possibly be hosted at ErlEF since it could be >> a „community recommendation“. >> >> Thanks & Best, >> Jonatan >> >> -- >> You received this message because you are subscribed to the Google Groups >> "elixir-lang-core" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to elixir-lang-core+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/elixir-lang-core/7744dfd3-e94e-45ed-bb10-ca6d5c732550n%40googlegroups.com >> <https://groups.google.com/d/msgid/elixir-lang-core/7744dfd3-e94e-45ed-bb10-ca6d5c732550n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- > You received this message because you are subscribed to the Google Groups > "elixir-lang-core" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to elixir-lang-core+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elixir-lang-core/lcum3vai.3a0f4bc0-3666-4af2-90bc-8381592ba17b%40we.are.superhuman.com > <https://groups.google.com/d/msgid/elixir-lang-core/lcum3vai.3a0f4bc0-3666-4af2-90bc-8381592ba17b%40we.are.superhuman.com?utm_medium=email&utm_source=footer> > . > -- Austin Ziegler • halosta...@gmail.com • aus...@halostatue.ca http://www.halostatue.ca/ • http://twitter.com/halostatue -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-core+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAJ4ekQs3%2BqXmiFhOiQkdZVX8sRob%3DFNw9agDH9jRy5J2UZmKgQ%40mail.gmail.com.
