There is also a tool called commitizen that helps teams standardise
commit messages. There is a Python implementation:
https://commitizen-tools.github.io/commitizen/
I’m not a huge fan of semantic commit messages and never personally used
any tooling for it, but one of commitizen’s co-maintainers is a friend
of mine, and I’ve been listening to his pitches for a while now, so I
guess I don’t really mind and can probably adapt to it if needed. As
long as we don’t use emoji tags
<https://gist.github.com/alpteo/e93d754e5e09907c6362c4230fb66f87>. Those
are terrible.
TP
"Janardhan" <[email protected]> (13/06/21 19:31:52):
Hi,
I am new to Apache Airflow.
May be the following example guide would also be helpful.
There is a commit style guide[1] for Apache SystemDS based it's commit
history over the last 10 years.
It lists the tags used, and provides the type of commits including a
list of attributes to be included in its description and example
commits.
Thank you,
Janardhan
[1]
https://github.com/apache/systemds/blob/master/CONTRIBUTING.md#commit-style
On Sunday, June 13, 2021, Tomasz Urbaszek <[email protected]> wrote:
Related discussion from last year ("Use semantic pull request"):
https://lists.apache.org/thread.html/r076232c60600238f37277497f66fb7eb9507869b92403c5ef96dcb3e%40%3Cdev.airflow.apache.org%3E
<https://lists.apache.org/thread.html/r076232c60600238f37277497f66fb7eb9507869b92403c5ef96dcb3e%40%3Cdev.airflow.apache.org%3E>
On Sun, 13 Jun 2021 at 12:56, Jarek Potiuk <[email protected]> wrote:
>
> Hey everyone,
>
> I would like to hear people's opinions on using
semantic/conventional
> commits. I see people occasionally using it, but unless we make it a
> "standard" and mandatory (and fail CI if commits are not following
> it), IMHO there is virtually no benefit for the whole community.
>
> I am now preparing the June provider's release (a little delayed due
> to my unavailability - sorry) and with 60+ providers it's somewhat
> manageable without it. I semi-automatically prepare and maintain all
> the changelogs now for all providers (I implemented a very simple
> heuristics to help with it and classify the commits based on the
> commit message) but it requires quite some effort to re-classify the
> changes. Not much, it's manageable, but having semantic/conventional
> commits would make my (and other release managers) life a bit
easier.
>
> For those who are not familiar with - here is the "gist" of it with
links:
> https://gist.github.com/joshbuchea/6f47e86d2510bce28f8e7f42ae84c716
<https://gist.github.com/joshbuchea/6f47e86d2510bce28f8e7f42ae84c716>
>
> In short - here are examples of semantic/conventional commit
messages:
>
> feat: add hat wobble
> fix: fix the hole eaten by moles
> doc: describe the hat etiquette
> style: make hat follow latest hat conventions
> refactor: replace hat underlying construction to be more sturdy
> test: test the hat when it's raining
> chore: cleanup the hat, it became dusty a bit
>
> Questions:
>
> * What's your experience with using the semantic/conventional
commits?
> * Do you like/dislike the semantic/conventional commits?
> * Should we make them mandatory?
> * Maybe there are other ways we can achieve the same results?
>
> J.
>
>
> --
> +48 660 796 129
