Why do we need braking changes. The only argument I read is: same function name, but not same function.
Anything else? -- Hard- and Softwaredevelopment Consultant Geschäftsführung: Simon Filgis USt-IdNr.: DE305343278 ISO9001:2015 <https://activities.ingenieurbuero-filgis.de/certifications> Tomek CEDRO <to...@cedro.info> schrieb am Mo., 11. Aug. 2025, 18:55: > > https://www.conventionalcommits.org/en/v1.0.0/#commit-message-with-both--and-breaking-change-footer > says: > > """ > Commit message with both ! and BREAKING CHANGE footer > > chore!: drop support for Node 6 > > BREAKING CHANGE: use JavaScript features not available in Node 6. > """ > > + we also require "Signed-off-by:" commit footer which is not part of > the Conventional Commits standard :-P > > I like Alin's idea best to put "!" as first character in git commit > and PR title this is the simplest possible marking no matter what goes > after and its easiest to parse :-) Maybe we should update Conventional > Commits? :D > > Thanks :-) > Tomek > > > > > > > On Mon, Aug 11, 2025 at 1:59 PM Alan C. Assis <acas...@gmail.com> wrote: > > > > Hi Tomek, > > > > Yes, I agree! We could require "!" in the title and "BREAKING CHANGE: " > in > > the git commit message. > > > > Although the conventional commits spec suggest one or other I think it > > makes sense to have both to make things clear. > > > > BR, > > > > Alan > > > > On Sun, Aug 10, 2025 at 7:30 PM 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 > > > > > > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info >
