Next major release ?

[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 fix(commands/bump): prevent using incremental changelog when it is set to false in config #996 (comment))

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 fix(changelog): handle custom tag_format in changelog generation #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:
  • feat: draft of the --empty parameter #723
  • create a dev bump straight after a normal bump #662
  • Cannot create release version after creating a pre-release version #1068
  • Flag to avoid creating a new commit for the bump #753
  • [Feature Request] Respect --allow-empty flag #247
  • Flag to avoid creating a new commit for the bump #753
• breaking: Centralize configurations and defaults. Single source of trust. Why not rely on pydantic:
  • changelog_incremental is set as default when calling changelog from cz bump #883
  • fix(commands/bump): prevent using incremental changelog when it is set to false in config #996 (comment)
• feature: pre and post bump hooks (entrypoints):
  • Add pre/post bump plugins #884
  • changelog_hook not called when "--dry-run" is passed #620
• feature: ensure that git specific messages are accepted by the pre-commit hook:
  • Option to allow fixup! and squash! in commit messages #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 #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