commitizen v4

[noirbizarre]

Description

Discuss and tracking breaking changes to include in the next major release.

Possible Solution

• [ ] drop all deprecation:
  • [ ] --version-type
• [ ] Review configuration handling (See https://github.com/commitizen-tools/commitizen/pull/996#issuecomment-1987334462)

Additional context

Should we release a major by breaking change or group them into a single major release ?

Additional context

No response

[Lee-W]

Not sure whether we need to create a 4.0 branch 🤔

[Lee-W]

I'm thinking of splitting version_schemes into smaller modules. Make both version_schemes and providers pluggable

[woile]

I'm thinking of splitting version_schemes into smaller modules

good idea, to be in-line with providers, and it would be easier to find them

Make both version_schemes and providers pluggable

what do you mean? they are already plugins, right?

[Lee-W]

what do you mean? they are already plugins, right?

ah, you're right. I forget it 🤦‍♂️

[woile]

We should improve the templates to make it easier to extend

[noirbizarre]

Brainstorming a few ideas (doesn't mean that we need everything in the next major):

• feature: extend https://github.com/commitizen-tools/commitizen/pull/995 to support (already started):
  • alt-tag-formats: to handle tag format changes. Legacy tags can still be parsed and included in the changelog
  • ignore-tag-formats: tag that are expected and should be ignored (should not result in a warning)
  • attach the version parts to the version scheme (working on semver2 made me realize that the current PR will only work for semver/pep440)
• feature: Make something for all the empty commits or release after prerelease issues:
  • https://github.com/commitizen-tools/commitizen/pull/723
  • https://github.com/commitizen-tools/commitizen/issues/662
  • https://github.com/commitizen-tools/commitizen/issues/1068
  • https://github.com/commitizen-tools/commitizen/issues/753
  • https://github.com/commitizen-tools/commitizen/issues/247
  • https://github.com/commitizen-tools/commitizen/issues/753
• breaking: Centralize configurations and defaults. Single source of trust. Why not rely on pydantic:
  • https://github.com/commitizen-tools/commitizen/issues/883
  • https://github.com/commitizen-tools/commitizen/pull/996#issuecomment-1987334462
• feature: pre and post bump hooks (entrypoints):
  • https://github.com/commitizen-tools/commitizen/issues/884
  • https://github.com/commitizen-tools/commitizen/issues/620
• feature: ensure that git specific messages are accepted by the pre-commit hook:
  • https://github.com/commitizen-tools/commitizen/issues/414

Given there is an autobump, maybe we can formalize a process to group new features and breaking changes together to reduce the bump of major/minor releases. Maybe using merge queues. I did not yet research what exists for that.

[woile]

Most of them look good.

I would avoid relying on pydantic as it's a widely used library. A lot of people attach commitizen to their dev-dependencies, and a lot of ppl use pydantic 1 or 2, probably creating problem. I heard today someone having issues with charset-normalizer

[Lee-W]

I also think https://github.com/commitizen-tools/commitizen/issues/950 might be something we want to correctly handle but could potential be a breaking change due to the difference between python packaging versioning and semver

[Lee-W]

Should we change this into a discussion and maybe create a few issues related to it? This looks more like a discussion instead of an issue to me

[Lee-W]

https://github.com/commitizen-tools/commitizen/issues/1135#issuecomment-2132814288

[Lee-W]

We might also want to include this one https://github.com/commitizen-tools/commitizen/pull/1209

[Lee-W]

@noirbizarre I just created a v4 branch. Also added some branch protection rule to this branch