Hi Tomek, It is not hiding the breaking change, it just avoids using it in the commit title for the reasons I explained before.
It is better to follow what other open-source projects do (like Linux kernel, Zephyr, etc) instead of creating something that is unique to our project and that could confuse users. If there is a standardized way to define "BREAKING CHANGE: " let's follow it. I think there is a good reason why nobody is using "[BREAKING]" in the git commit title these three months. So, let's avoid adding it to the commit title, let's follow the conventional commits! BR, Alan On Sat, Aug 9, 2025 at 6:45 PM Tomek CEDRO <to...@cedro.info> wrote: > On Sat, Aug 9, 2025 at 11:10 PM Tomek CEDRO <to...@cedro.info> wrote: > > > > 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. > > Btw this discussion started in https://github.com/apache/nuttx/pull/16793 > where: > 1. one function is deleted. > 2. another function is renamed to the first function. > 3. thus we are clearly breaking API by replacing existing function > with different parameters, functionality, and code inside. > > I know this change makes some things simpler without loosing > functionality and may be desired. I am okay with that. But other > people also reported it as breaking. I am not okay with avoiding clear > mark that someone's code will break after some change. > > Hiding [BREAKING] or that new "!" mark from git logs and pr / > changelog is a deliberate hide of breaking changes, just as is not > following the Contribution Guide. > > I do not understand why you guys want to hide breaking changes so > much? Just as other FTL related changes were not marked as breaking. I > just don't get it, its like shooting yourself in the foot :-( > > Is only amount of whatever change that matters nowadays? > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info >
