Why doesn’t Phoenix use Conventional Commit prefixes?

Can’t speak for phx - but i’ve been using conventional commits for my open source stuff, i put it down to a matter of style and preference.

I particularly like it for calculating SemVers and the uniform feel of changelogs.

If you’re exploring them, I’d have a look at something like GitHub - cocogitto/cocogitto: The Conventional Commits toolbox · GitHub , which makes conventional commits trivial to use.

Quite a few projects do use Conventional Commits, notably the Ash suite of libs.

A good library for implementing Conventional Commits in Elixir is GitOps. It handles versioning based on commit types, tagging, managing changelogs, updating the latest version number in documentation e.g. README.md, etc.

Can’t speak for the phoenix project.

I tend to use them in my own projects. I find them a helpful signal, but not a requirement. To me, it is a sign that the project is detail-oriented.

In my repo I use a workflow to enforce this style:

https://github.com/zorn/dustoff/blob/main/.github/workflows/lint-pr.yaml

Personally I greatly dislike the “conventional commit” style and prefer descriptive, sentence case commits with additional context. I’ll rewrite the message for pull requests that start with “feat:” to match the style of the repository.

When it comes to the changelog, I group bugs and enhancements, but do it when I’m writing the changelog. The messages usually get expanded into something more descriptive as well.

I also prefer sentence case in the imperative tense matching git’s auto-generated merge commits, ie, “Merge a into b”. There’s no period because, no matter what anyone tells you, it’s a subject line that hopefully has a body Also, if you happen to be vehemently against squashing PRs (although it does make sense in many libraries) then conventional commits feel like they’d be an annoyance.

Ultimately it doesn’t matter so long as it’s consistent. Of course, multiple companies I’ve worked for don’t even care about consistency so I’ve largely stopped stressing about it and sometimes just do git commit -am "changes".

Apologies for the rant

Any standard is probably better than no standard.

I’d like to make git_ops support a tag type syntax for commits in addition to conventional commits.

improvement: make the frobnicator work better

some more details

could easily be

make the frobnicator work better

#improvement
#breaking-change

Or other potential formats. It would be a really simple change to our parser. The point for me is just being able to get that info from the commits, not the actual format. It would probably be trivial to implement.

In case anyone is interested in the features (automatic changelog generation and version numbering) but don’t want to use conventional commits, PRs welcome to git_ops
I might even switch to something like that for the Ash project at some point.

We also just added logic to use the GitHub API to include links to the user who contributed a change where possible as part of generating a changelog etc. Conventional commits is just an implementation detail at the moment.

I remember you introducing this but I assume I wrote it off due to the conventional commit dependency. It’s cool that you’re considering an alternative as this looks really useful. I’m still not 100% sure I’d use it but hypothetically would you be open to a PR for making it available as an escript? None of my (active) open source projects are Elixir. Or is this just meant for Elixir projects (looking through the README it doesn’t seem that way). EDIT: oh right the config would maybr have to support JSON or toml or something in this case?

Yes, happy to use json or toml config to support being an escript or some other type of thing

Thanks so much for all the thoughtful and detailed replies!

I really appreciate the mentions of GitOps and the lint workflow.

As I read the arguments for sentence case in the imperative tense, I now find it more logical than the sometimes redundant prefixes.

For now, I tend to stick with sentence case in the imperative tense to keep things consistent in my current library.

Thanks again!