Hi all, I agree with Tomek that we should mark both the commit and PR.
Alan's idea is really good since BREAKING takes several characters that can be used to create a better title. I propose that we use an exclamation mark at the beginning of commit and PR title What do you think ? Best regards Alin On Mon, Aug 11, 2025 at 12:30 AM Tomek CEDRO <to...@cedro.info> wrote: > The real problem here is that breaking changes were passed unmarked :-( > > We can change marking no problem, but we need some sort of mark both > in git commit topic and PR title, do you agree Alan? > > Tomek > > On Sun, Aug 10, 2025 at 3:50 PM Alan C. Assis <acas...@gmail.com> wrote: > > > > 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 > > > > > > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info >
