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

[paodb]

My thought is that we can probably just handle this during the release process. If a fix is in the same PR, we squash it. If it's a separate fix for an unreleased feature, whoever is handling the release can just delete that line from the notes before publishing. A quick manual check on the notes seems like a good idea regardless.

I'd rather do that than add a new commit type for everyone on the team to learn and remember. I think inc: could just add mental overhead and lead to debates over when to use it.

It just seems simpler to handle this with our existing process. Am I missing a downside to that approach?

[javier-godoy]

My thought is that we can probably just handle this during the release process [...] whoever is handling the release can just delete that line from the notes before publishing [...] Am I missing a downside to that approach?

There are several potential downsides to consider.

The True Cost is Hidden: The time and effort spent curating release notes is a hidden cost to the project. This makes it difficult to argue for improvements, as the majority of the team isn't even aware that problem even exists.

It Undermines Automation: A primary benefit of Conventional Commits is the ability to fully automate changelog generation. Introducing a required manual step negates much of this benefit, turning an automated process into a semi-automated one that requires human intervention and judgment for every release.

Prone to Human Error: Any manual process is susceptible to mistakes. The person handling the release might forget to review the notes, overlook an relevant commit, or mistakenly delete a line that should have been included. This can lead to inaccurate, incomplete, or unprofessional release notes.

Scalability Issues: As a project grows in terms of contributors, commit volume, and release frequency, the task of manually vetting the release notes becomes increasingly burdensome and error-prone. What is a quick check in a small project can become a significant bottleneck in a larger one.

Requires Deep Context: To correctly decide which fix commits to delete, the release manager needs to have a deep understanding of the development history. They need to know which features were unreleased at the time a fix was committed. This knowledge is not always easily transferable, creating a dependency on specific team members and making the release process harder for new contributors to manage.

Inconsistent Results: Different people may have different criteria for what constitutes a "fix for an unreleased feature." This can lead to inconsistency in the style and content of release notes from one release to the next, depending on who is managing it.

In summary, while the manual approach offers simplicity by avoiding a new commit type, its main downside is that it sacrifices the reliability, scalability, and automation that conventions like Conventional Commits are designed to provide. It shifts the burden from a one-time decision on commit formatting to a repeated, manual task for every release, which introduces risk and process overhead.