I also don't like conventional commits - and ultimately I don't think for commit logs are the right tool for building a changelog - they are too granular and also too noisy.
Primary reasons for not liking them: it uses up a lot of space in the already short commit subject "limit", it's subjective, it can't be changed after the commit is merged. If the goal is to make building change logs easier and more useful I'd rather we used a tool designed for that - https://docs.openstack.org/reno/latest/ This also natively handles our cheery pick process, and also gives us the ability to edit changelogs if we notice a typo for instance. -ash On 14 June 2021 03:39:50 BST, Tzu-ping Chung <[email protected]> wrote: >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
