Giters

conventional-commits / conventionalcommits.org

The conventional commits specification

Home Page:https://conventionalcommits.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Breaking changes and `refactor` (and maybe `style`) type.

kennylajara opened this issue · comments

commented

By definitions, a refactor can not introduce changes, so, I think it is worth mentioning that we should never create a commit message:

refactor!: This is weird

Also, what do you think about style? Can a style change introduce a breaking change?

commented

By definitions, a refactor can not introduce changes, so, I think it is worth mentioning that we should never create a commit message:


refactor!: This is weird

Also, what do you think about style? Can a style change introduce a breaking change?

commented

Hi @Thiernosy82,
Did you forget to add your comment? Or is this some kind of retweet?

commented

I disagree.

"A refactor can not introduce changes" is an assertion that one human-level dictionary definition is the only correct one.

Yes, one definition of "refactor" is a code change with no change to behavior. This is a good definition. I would even argue that in some situations it is the Objectively Rightest definition to use. But that is not the only (good) definition in use today.

If Conventional Commits goes out of its way to forbid combining "this is a refactor" and "this broke some bit of promised API", there should be a strong argument that there is a big benefit to preventing saying it (or forcing it to be said in a way that's just harder to parse/notice).

A few arguments the other way:

  • Principled: it's similar to how composable APIs are good and unnecessary coupling/complecting in code is bad: it's good to keep specs for ways to say things separate from prescriptions about what should or shouldn't be said/done.

  • Principled+Practical: Many people prefer a more flexible meaning of "refactor", and for good reason. Some breaking changes are more refactor-like than fix-like or feature-like. Some breaking changes are only/mainly to enable a valuable refactor.

  • Practical: humans make refactors that break API all the time. Under time pressure and competing priorities, if we notice a refactor breaks API, sometimes the better/necessary decision is to just announce the breakage and move on, not refactor the refactor or philosophize about what other word to use.

commented

P.S. Note that Conventional Commits v1.0.0 does not even define a refactor change type - so technically, you could define your own additional convention which extends Conventional Commits by defining a refactor type and disallowing composing it with breaking changes, or a convention for tooling to follow (like "if the environment variable COMMITS_REQUIRE_PURE_REFACTOR is set to a truthy value, reject/warn upon encountering refactor-typed commits with breaking changes).

commented

Well-served by #537 - if I was writing Conventional Commits tooling/libraries, I'd love to have a central place to find good ideas and well-designed proposals for extensions such as "if the environment variable [...] is set, reject/warn upon encountering refactor-typed commits with breaking changes".