On Sat, Aug 9, 2025 at 9:47 PM Alan C. Assis <acas...@gmail.com> wrote: > > Hi Everyone, > > I'm proposing to modify the item 1.13.9 from our CONTRIBUTING.md to avoid > including the prefix "[BREAKING]" in the commit title for the following > reasons: > > * It passes a wrong message, as something very negative (not all > breaking are bad, or shouldn't be) > * Someone reading our git history could get a wrong impression of the > project > * It will cluttering the title, by convention the title should have only 50 > chars > * It doesn't follow the conventional commits specification: > https://www.conventionalcommits.org/en/v1.0.0/ > > So, please verify the suggested modification here: > https://github.com/apache/nuttx/pull/16823 > > The suggestion as defined by conventional commits is to include the > "BREAKING CHANGE: " in the commit log message (foot).
Thanks Alan, but I don't agree. We have this 1.13.9 requirement for over 3 months and it seems to be ignored on purpose :-( This came after long discussions and voting. Now we want to discard that? Are there +1 points given for standard commit and -10 points taken for breaking change commit anywhere? We _must_ clearly mark breaking changes. These cannot be hidden. People will leave project if we don't. There is no "wrong message" or nothing "negative" in [BREAKING] mark. You can say the same about "!" mark and "BREAKING CHANGE" in the commit body. This is about API not hearts. It clearly points to a change that will break people code. We should avoid breaking changes, but when they happen these should be clearly visible and easy to find in git log and PRs/changelogs (changelog is built from pr topic so pr topic must contain some sort of breaking change mark). Github "tag" is not enough because after you fetch the code you will not see that tag in the git log. People will get wrong impression when they base their project and instead two days of work they have to spend 2 weeks or months and then after update noting works. If we clearly mark breaking changes they will quickly know how to fix things and the trust preserves. Trust is more important than impression. People will get wrong impression if we hide breaking changes on purpose. Conventional Commits version 1.0 is around one year old. Are there tools / projects who adopted them widely? Is this world standard? We do have requirements for commit messages. [BREAKING] is really simple and self-explanatory. If you think only about cosmetics by replacing "[BREAKING]" tag with "!:" and "BREAKING CHANGE" then if the community prefers this one then okay. But we should mark both git commit and PR topic that way so things are coherent both in git logs and pr / changelogs and for sure we must not hide breaking changes in any possible way. -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
