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.

Reply via email to