I like that idea 👍 We have a nimble_parsec commit parser, so we could add support for extending the formats we accept.
On Fri, Jan 13, 2023 at 11:06 AM, Austin Ziegler < halosta...@gmail.com > wrote: > > 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. daniel@ gmail. com > ( zachary.s.dan...@gmail.com ) > wrote: > > >> My library git_ops https:/ / github. com/ zachdaniel/ 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/ ( >> 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 < jonatan@ maennchen. ch ( >> 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 ( http://changelog.md/ ) file >>> * GitHub release is automatically created >>> * Artifacts are stored in release >>> * manual copy of text into GitHub release >>> >>> >>> >>> * ExDoc >>> >>> * global CHANGELOG. md ( http://changelog.md/ ) file >>> * manual copy of entry into GitHub releases >>> >>> >>> >>> * GenStage >>> >>> * global CHANGELOG. md ( http://changelog.md/ ) file >>> * no GitHub releases >>> >>> >>> >>> * ElixirMake >>> >>> * global CHANGELOG. md ( http://changelog.md/ ) file >>> * no GitHub releases >>> >>> >>> >>> >>> >>> >>> * Phoenix >>> >>> * per minor release CHANGELOG. md ( http://changelog.md/ ) >>> * some GitHub releases were created, not up-to-date >>> >>> >>> >>> * Tzdata >>> >>> * global CHANGELOG. md ( http://changelog.md/ ) >>> * no GitHub releases >>> >>> >>> >>> * Jason >>> >>> >>> * global CHANGELOG. md ( http://changelog.md/ ) >>> >>> * manual GitHub releases >>> >>> >>> >>> >>> * Plug Cowboy >>> >>> * per major version CHANGELOG. md ( http://changelog.md/ ) >>> >>> * manual GitHub releases >>> >>> >>> >>> >>> * Telemetry >>> >>> * global CHANGELOG. md ( http://changelog.md/ ) >>> * outdated GitHub releases >>> >>> >>> >>> >>> >>> >>> >>> *Possibilities for standardization:* (i can think of, reply with others if >>> you think something is missing) >>> >>> >>> >>> >>> * Only CHANGELOG. md ( http://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 ( http://changelog.md/ ) + GitHub releases manual copy >>> >>> * On release the CHANGELOG. md ( http://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 ( http://changelog.md/ ) & Automated GitHub release note >>> >>> * On release the CHANGELOG. md ( http://changelog.md/ ) file is extended >>> and a GitHub workflow will parse the CHANGELOG. md ( http://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 ( >>> http://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 ( >>> http://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 ( http://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 ( http://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+unsubscribe@ googlegroups. com ( >>> 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+unsubscribe@ googlegroups. com ( >> 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 • halostatue@ gmail. com ( halosta...@gmail.com ) • austin@ > halostatue. ca ( aus...@halostatue.ca ) > http:/ / www. halostatue. ca/ ( http://www.halostatue.ca/ ) • http:/ / > twitter. > com/ halostatue ( 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+unsubscribe@ googlegroups. com ( > 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 ( > https://groups.google.com/d/msgid/elixir-lang-core/CAJ4ekQs3%2BqXmiFhOiQkdZVX8sRob%3DFNw9agDH9jRy5J2UZmKgQ%40mail.gmail.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/lcupqozu.16dc18d3-4476-4204-b096-cd5496664146%40we.are.superhuman.com.