kuwv
commented
3 months ago @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.
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