Repository navigation
commitizen v4 #1073
Description
Activity
Not sure whether we need to create a
4.0branch 🤔I'm thinking of splitting version_schemes into smaller modules. Make both version_schemes and providers pluggable
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?
what do you mean? they are already plugins, right?
ah, you're right. I forget it 🤦♂️
We should improve the templates to make it easier to extend
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 changelogignore-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: add --allow-no-commit option #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: - feature:
preandpostbump hooks (entrypoints): - feature: ensure that git specific messages are accepted by the pre-commit hook:
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.
Reacted by Santiago Fraire Willemoes and Wei Lee- feature: extend fix(changelog): handle custom tag_format in changelog generation #995 to support (already started):
Most of them look good.
I would avoid relying on
pydanticas 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 withcharset-normalizerReacted by Wei LeeShould 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
@noirbizarre I just created a v4 branch. Also added some branch protection rule to this branch
Description
Discuss and tracking breaking changes to include in the next major release.
Possible Solution
--version-typeAdditional context
Should we release a major by breaking change or group them into a single major release ?
Additional context
No response