docs: add version bump annotations to all commit type descriptions

commitizen/cz/conventional_commits/conventional_commits.py

@@ -62,49 +62,50 @@ def questions(self) -> list[CzQuestion]:
                     },
                     {
                         "value": "docs",
-                        "name": "docs: Documentation only changes",
+                        "name": "docs: Documentation only changes. No version bump",
                         "key": "d",
                     },
                     {
                         "value": "style",
                         "name": (
                             "style: Changes that do not affect the "
                             "meaning of the code (white-space, formatting,"
-                            " missing semi-colons, etc)"
+                            " missing semi-colons, etc). No version bump"
                         ),
                         "key": "s",
                     },
                     {
                         "value": "refactor",
                         "name": (
                             "refactor: A code change that neither fixes "
-                            "a bug nor adds a feature"
+                            "a bug nor adds a feature. Correlates with PATCH in SemVer"
                         ),
                         "key": "r",
                     },
                     {
                         "value": "perf",
-                        "name": "perf: A code change that improves performance",
+                        "name": "perf: A code change that improves performance. Correlates with PATCH in SemVer",
                         "key": "p",
                     },
                     {
                         "value": "test",
-                        "name": ("test: Adding missing or correcting existing tests"),
+                        "name": ("test: Adding missing or correcting existing tests. No version bump"),
                         "key": "t",
                     },
                     {
                         "value": "build",
                         "name": (
                             "build: Changes that affect the build system or "
-                            "external dependencies (example scopes: pip, docker, npm)"
+                            "external dependencies (example scopes: pip, docker, npm). "
+                            "No version bump"
                         ),
                         "key": "b",
                     },
                     {
                         "value": "ci",
                         "name": (
                             "ci: Changes to CI configuration files and "
-                            "scripts (example scopes: GitLabCI)"
+                            "scripts (example scopes: GitLabCI). No version bump"
                         ),
                         "key": "c",
                     },

commitizen/cz/conventional_commits/conventional_commits_info.txt

@@ -7,21 +7,29 @@ fix: a commit of the type fix patches a bug in your codebase
 feat: a commit of the type feat introduces a new feature to the codebase
 (this correlates with MINOR in semantic versioning).
 
+refactor: a commit of the type refactor is a code change that neither
+fixes a bug nor adds a feature
+(this correlates with PATCH in semantic versioning).
+
+perf: a commit of the type perf is a code change that improves performance
+(this correlates with PATCH in semantic versioning).
+
 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.
 
-Others: commit types other than fix: and feat: are allowed,
-like chore:, docs:, style:, refactor:, perf:, test:, and others.
+Others: commit types other than fix:, feat:, refactor:, and perf: are allowed,
+like chore:, docs:, style:, test:, build:, ci:, and others.
+These types do not trigger a version bump by default.
 
 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).
 
-A scope may be provided to a commit’s type, to provide additional contextual
+A scope may be provided to a commit's type, to provide additional contextual
 information and is contained within parenthesis, e.g., feat(parser): add ability to parse arrays.
 
 <type>[optional scope]: <description>

docs/tutorials/writing_commits.md

@@ -20,24 +20,24 @@ The Conventional Commits specification follows this structure:
 
 ### Commit Types
 
-Commit types categorize the nature of your changes. The most important types for semantic versioning are:
+Commit types categorize the nature of your changes. By default, Commitizen uses the [Angular Convention](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines) commit types. The following types affect semantic versioning:
 
 - **`feat`**: Introduces a new feature (correlates with **MINOR** version increment)
 - **`fix`**: Patches a bug (correlates with **PATCH** version increment)
+- **`refactor`**: A code change that neither fixes a bug nor adds a feature (correlates with **PATCH** version increment)
+- **`perf`**: A code change that improves performance (correlates with **PATCH** version increment)
 
-Other commonly used types include:
+The following types do **not** trigger a version bump by default:
 
-- **`docs`**: Documentation only changes
-- **`style`**: Code style changes (formatting, missing semicolons, etc.)
-- **`refactor`**: Code refactoring without changing functionality
-- **`perf`**: Performance improvements
-- **`test`**: Adding or updating tests
-- **`build`**: Changes to build system or dependencies
-- **`ci`**: Changes to CI configuration files
-- **`chore`**: Other changes that don't modify source or test files
+- **`docs`**: Documentation only changes (no version bump)
+- **`style`**: Code style changes such as formatting, missing semicolons, etc. (no version bump)
+- **`test`**: Adding or updating tests (no version bump)
+- **`build`**: Changes to build system or dependencies (no version bump)
+- **`ci`**: Changes to CI configuration files (no version bump)
+- **`chore`**: Other changes that don't modify source or test files (no version bump)
 
 !!! note
-    While `feat` and `fix` directly affect semantic versioning, other types (like `build`, `chore`, `docs`) typically don't trigger version bumps unless they include a `BREAKING CHANGE`.
+    Only `feat`, `fix`, `refactor`, and `perf` trigger version bumps by default. All other types (like `docs`, `style`, `test`, `build`, `ci`, `chore`) do not trigger version bumps unless they include a `BREAKING CHANGE`. You can customize this behavior through the [bump_map configuration](../customization/config_file.md).
 
 ### Breaking Changes