Giters

conventional-commits / conventionalcommits.org

The conventional commits specification

Home Page:https://conventionalcommits.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Conventional Commits Versioning

mentalisttraceur opened this issue · comments

commented

The Conventional Commit specificiation would benefit from an explicit definition of what its own version numbers mean.

For example, let's say I convince you to add feature as a synomym of feat. Is that Conventional Commits v1.0.1, v1.1.0, or v2.0.0?

  1. I really hope it's not v1.0.1, but right now I don't see anything that guarantees that. It would be nice to see an explicit guarantee that the "patch"-level spec changes are just for fixing wording and covering edge cases which make the spec unsound, self-contradictory, etc - in other words, just like a code bugfix should only break usage which every reasonable API reader would agree was incorrect reliance on unpromised behavior, a spec bugfix should only break implementations which every reasonable spec reader would agree was incorrect interpretation).

  2. It probably shouldn't be v2.0.0, because the major version bump should probably be reserved for the most important kind of change. For a spec, near as I can tell, the most important change type is changes that create at least one case where it is either impossible to produce data compatible with old parsers, or impossible to implement new parsers compatible with both old and new data. It would be nice to have an explicit guarantee that "major"-level spec changes are just for that.

  3. So it probably ought to be v1.1.0, because parsers for the new spec can still parse every commit written to the old spec, and you can still write commits per the new spec which are parseable by the old spec. And again, it would be nice to have an explicit guarantee that "minor"-level spec changes are for that.

(If there is interest+agreement, I'd be happy to distill this idea into a standalone "SemVer (clarified) for Specificiations (and Protocols)" document ("SpecVer"?), give it a SemVer-style website. Well, I will probably do it anyway, but interest/agreement would get me to do it sooner. Then Conventional Commits could just say "Conventional Commits version numbers follow SpecVer v1.0.0".)

commented

Adding a synonym would be a feature, so it would fall under 1.1.0.

Pretty simple tbh

commented

@paul-uz I can't tell if you're agreeing with me or if we're talking past each other. I already said I think my example ought to be 1.1.0, so we agree there.

  1. I want the Conventional Commits spec to explicitly promise that it's versions are SemVer-like, so that we don't have to assume.

  2. How, precisely, do we decide it's a "feature"? I want to drag that out into words. It takes SemVer several sentences to define "feature" for APIs (and even that definition only works if you completely define your public API with similar rigor). That's why I'm offering a definition of "feature" for specs along the lines of

    parsers for the new spec can still parse data produced per the old spec, and you can still produce data per the new spec which parse to the same thing in the old spec

commented

Eurgh. Please stop posting.

commented

Eurgh. Please stop posting.

This isn't an answer to the question, and is IMO against the code of conduct.

  • Using welcoming and inclusive language
  • Being respectful of differing viewpoints and experiences
  • Gracefully accepting constructive criticism
  • Focusing on what is best for the community
  • Showing empathy towards other community members

And:

  • Other conduct which could reasonably be considered inappropriate in a professional setting

I have reported this interaction to enforcement.