search

conventional-changelog / conventional-changelog-config-spec

a spec describing the config options supported by conventional-config for upstream tooling
109 stars 32 forks source link

[QUESTION] Minor vs Patch Bump #29

Closed redreceipt closed 4 years ago

redreceipt commented 4 years ago

I apologize for the spam but there's something I don't understand and I can't find an answer anywhere.

Does it always bump the minor number unless you prefix fix? I guessed with chore it would still bump the patch number but is that not the case?

jbottigliero commented 4 years ago

Hey @redreceipt – the configuration spec doesn't actually enforce any rules here.

If you are using the Conventional Commits specification (repo), which is the default preset on much of the conventional-changelog tooling, fix and chore will both be treated as PATCH bumps.

redreceipt commented 4 years ago

Is there any text that shows what prefix corresponds to what version bump? I can't seem to find it, even at the links you mentioned. And how do I know if I'm using the Conventional Commits specification?

jbottigliero commented 4 years ago

Is there any text that shows what prefix corresponds to what version bump?

@redreceipt you can find that information in the Conventional Commits specification. This excerpt, in particular, defines how it should map to semantic versioning:

The commit contains the following structural elements, to communicate intent to the consumers of your library:

  1. fix: a commit of the type fix patches a bug in your codebase (this correlates with PATCH in semantic versioning).
  2. feat: a commit of the type feat introduces a new feature to the codebase (this correlates with MINOR in semantic versioning).
  3. BREAKING CHANGE: a commit that has the text BREAKING CHANGE: at the beginning of its optional body or footer section introduces a breaking API change (correlating with MAJOR in semantic versioning). A BREAKING CHANGE can be part of commits of any type.
  4. Others: commit types other than fix: and feat: are allowed, for example @commitlint/config-conventional (based on the Angular convention) recommends chore:, docs:, style:, refactor:, perf:, test:, and others.

We also recommend improvement for commits that improve a current implementation without adding a new feature or fixing a bug. Notice these types are not mandated by the conventional commits specification, and have no implicit effect in semantic versioning (unless they include a BREAKING CHANGE).

https://www.conventionalcommits.org/en/v1.0.0-beta.4/

And how do I know if I'm using the Conventional Commits specification?

This will depend on your tooling for generating releases and/or changelogs – are you using standard-version?

redreceipt commented 4 years ago

Point 4 in your above comment doesn't specify, do they correlate to PATCH or MINOR?

Yes I am using standard-version

jbottigliero commented 4 years ago

Using standard-version they'll be treated as PATCH bumps. The only time standard-version will not adhere to the rules in the specification are when your version is pre-release (<1).

redreceipt commented 4 years ago

Thank you!