[ivan_gammel]

There’s a common convention that starts commit message with ticket numbers. Why tickets are not mentioned in the spec? This context is more important.

Regarding choice of types: why „feature“ is shortened to „feat“? If there’s a type for feature, why another type is „fix“, not a „bug“? Semantically naming should be consistent.

Automatic relationship with semver is questionable. Fix can be a change in architecture that deserves major version. Implementation of non-functional requirements is not a fix, yet it does not introduce new features and thus not a minor version increment. These are just two examples where inferred version is not what it could be. Making possible explicit expression of intent would help, e.g. by adding some tag like [minor]. Example:

   „APP-143:fix:major - migrated from mongodb to postgres“

   „123456:new:patch — added logging of requests“

[shoo]

I completely agree that linking to additional supporting docs that explain requirements, design, etc is very helpful. Especially for the crew of poor bloody maintenance contractors trying to reverse engineer the system requirements and constraints from the commit history a decade or two into the future, after everyone else originally involved with hauling the system into production has escaped/retired/died/fled changing their names and CVs.

I've had some coworkers argue that the first line of the commit ("subject line" in git) is very important real estate, not to be wasted on a ticket reference, where it could instead hold a human readable summary. There's some merit to that. But they'd still include a reference to the ticket inside the body of the commit.

Depending on how excitable one's org is about creating and migrating between issue trackers, sometimes a ticket reference can still be very ambiguous. I've seen one enterprise project migrate between different JIRA instances within the space of a couple of years, where depending on which instance you plugged the same ticket reference into, you'd get a completely different ticket!

[regularfry]

Jira integration is one place I've seen some real horrors - feature gets marked as "done" with a link to a git hash, then that patch gets bundled into a massive squash merge with a "changelog" that just says " merge 1/8/2022" and the feature branch deleted so the git hash gets lost. No traceability whatsoever.

[diarrhea]

You would have a painful time if large but innocuous architectural changes introduced major version bumps. Semantic versioning is how many packaging ecosystems nowadays work and decide compatibility. There is only one question to answer: Did the architecture change change the public API? No: even if this was an entire application rewrite, users don’t care. This is not a new major. Perhaps not even a minor (this is subjective I guess). Yes: it’s a breaking change and warrants a major version bump. So the scale of changes is sometimes at odds with the scale of the resulting version bump. Huge changes might not even be fixes, single-line changes might result in major version bumps. All this is highly important for libraries to adhere to. Binaries/programs possibly less so.

[regularfry]

> Implementation of non-functional requirements is not a fix, yet it does not introduce new features and thus not a minor version increment.

Bumping the minor version for this is fine in semver. It's a MAY in the spec.