Skip to content

Feature request graveyard

This page contains features and designs that have been proposed or considered but won't be implemented in Commitizen.

For a comprehensive list, please refer to our issue tracker.

Enable multiple locations of config file .cz.* #955

Create a flag to build the changelog from commits in multiple git repositories #790

Global Configuration #597

Why are revert and chore valid types in the check pattern of cz_conventional_commits but not types we can select?

revert and chore are added to the pattern in cz check in order to prevent backward errors, but officially they are not part of conventional commits, we are using the latest types from Angular (they used to but were removed). However, you can create a customized cz with those extra types. (See Customization).

See more discussion in

Why does Commitizen not support CalVer?

commitizen could support CalVer alongside SemVer, but in practice implementing CalVer creates numerous edge cases that are difficult to maintain (#385) and more generally, mixing the two version schemes may not be a good idea. If CalVer or other custom versioning scheme is needed, commitizen could still be used to standardize commits and create changelogs, but a separate package should be used for version increments.

Mixing CalVer and SemVer is generally not recommended because each versioning scheme serves a different purpose. Diverging from either specification can be confusing to users and cause errors with third-party tools that don't expect the non-standard format.

In the future, commitizen may support some implementation of CalVer, but at the time of writing, there are no plans to implement the feature (#173).

If you would like to learn more about both schemes, there are plenty of good resources:

Why don't we use Pydantic?

While Pydantic is a powerful and popular library for data validation, we intentionally avoid using it in this project to keep our dependency tree minimal and maintainable.

Including Pydantic would increase the chances of version conflicts for users - especially with major changes introduced in Pydantic v3. Because we pin dependencies tightly, adding Pydantic could unintentionally restrict what other tools or libraries users can install alongside commitizen.

Moreover we don't rely on the full feature set of Pydantic. Simpler alternatives like Python's built-in TypedDict offer sufficient type safety for our use cases, without the runtime overhead or dependency burden.

In short, avoiding Pydantic helps us:

  • Keep dependencies lightweight
  • Reduce compatibility issues for users
  • Maintain clarity about what contributors should and shouldn't use