Add type for incremental changes

[javier-godoy]

Consider the following commits:

feat: implement Foo
fix: fix Foo
fix: fix the other issue in Foo
build: release version 1.1.0

If the release notes are derived from the commit messages, they would include as changes in version 1.1.0:

• New features: implement Foo
• Bugfixes: fix Foo, fix the other issue in Foo

The release notes should only mention "implement Foo" since fixes on the new feature are just part of its initial implementation (depending on the git workflow, it's possible that feat lands in the main branch before the fixes are implemented).

Therefore, I propose the following type:

inc: Incremental changes to a feature, which do not contribute to the release notes.

feat: implement Foo
inc: fix Foo
inc: fix the other issue in Foo
build: release version 1.1.0

[mlopezFC]

The problem that I see with this is that what if you have several "feat"s and several "inc"s, we should basically ignore the mapping between them? ... and this can also be solved by squashing before creating the PR or squashing the whole PR. The other problem that I see is that "exaggerating" this, one could just create a small commit with the starting point of a given feat, and then just a series of "inc", so that will be almost the same as squashing them. If the "inc"s are going to be ignored in the release notes, maybe it's better to just squash them.
I'm still not sure at this point ... is there anything that I could be missing in my analysis?

[javier-godoy]

With proper usage (which I'm trying to define) it's kind of a corner case, but it happens.

See for instance this commit. It's a fix for an issue introduced in this other commit, and it doesn't stand on its own, but it also affects the existing feature (thus I separated it from the feat commit); however it isn't a fix for the existing feature, thus nobody would be interested on knowing that not only I added a feature, but also fixed an issue that happened when both features were used together (because that bug was never released).

Granted, we can squash them if needed (since both commits are in the PR). Now think what would have happened had the PR been merged before realizing it was a bug:

feat: implement a feature
fix: fix a bug that nobody cares about (it will be included in the release notes because the feature was already merged)

feat: implement a feature
inc: fix a bug that nobody cares about and thus it won't be mentioned in the release notes