Decoupling from specific versioning formats (i.e. SemVer)

[FCamborda]

Hi,
this is a very nice initiative! I understand and benefit of coupling commits with changelog specifics (i.e. sections "added", "fixed", "removed", etc).
However, when reading the documentation I see there's a lot of wording related to SemVer, which is not a bad thing, but makes me believe that it's the only supported versioning scheme?
I think either more wide-spread options should be mentioned (e.g. CalVer) or none is explicitly mentioned. The problem that I see with the current specification is that it includes "breaking" in a very SemVer-ish way, which by modern literature does not acknowledge other aspects of versioning in large-scale environments.

Further reads:
https://abseil.io/resources/swe-book/html/ch21.html
https://hynek.me/articles/semver-will-not-save-you/

This might make other developers believe that tooling aligned with ConventionalCommits should support SemVer, when in my eyes there's a big benefit of making them agnostic w.r.t. versioning format

[kuwv]

@FCamborda the argument of the second article that "project x" (cryptography in this case) doesn't follow SemVer (or PEP440) and that semver-will-not-save-you is circular logic. Which is ironic because it broke Pipenv which is designed to lock dependencies for deployments.

As you noted, CalVer doesn't yet define a breaking change. Tools that conform to conventional commits and automate change log creation do however. Removing this would make CalVer less useful for tracking and notifying developers of these log entries. IMO this complements CalVer more instead of less.

Really, I see SemVer and CalVer as complementary but targeting different use cases.

[FCamborda]

@kuw thanks for the reply!
I'm not really interested in discussing whether SemVer or CalVer is the right way to go. I was just wondering if conventional commits has an option to be less related to semver, so that calver users can align with this.

Precisely, we do not work with items like BREAKING CHANGE as this is not always guaranteed.

BREAKING CHANGE: a commit that has a footer BREAKING CHANGE:, or appends a ! after the type/scope, introduces a breaking API change (correlating with MAJOR in Semantic Versioning). A BREAKING CHANGE can be part of commits of any type.

[kuwv]

@FCamborda IME conventional commits actually align more with numeric / sequence versioning (example 0.1.0.0) than SemVer.

I obviously can't speak for the intent of the writer. But, this effort is intended to standardize the process used by the Angular project. You may be able to glean more there.

The compatibility issue is clearer when you look at mapping the flow for alpha, beta and release-candidate which should each begin with their own dev version before being finalized. Ideally you would go from 0.1.0 to 1.0.0-a1.dev0 to begin prototyping this major change. Here there is no help from CC to walk that flow to either 1.0.0-a1 or 1.0.0-a1.dev1.