Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

commitizen v4 #1073

Open
3 tasks
noirbizarre opened this issue Apr 18, 2024 · 12 comments
Open
3 tasks

commitizen v4 #1073

noirbizarre opened this issue Apr 18, 2024 · 12 comments
Labels
issue-status: wait-for-implementation maintainers agree on the bug / feature v4

Comments

@noirbizarre
Copy link
Member

Description

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

Possible Solution

Additional context

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

Additional context

No response

@Lee-W
Copy link
Member

Lee-W commented Apr 21, 2024

Not sure whether we need to create a 4.0 branch 🤔

@Lee-W
Copy link
Member

Lee-W commented Apr 23, 2024

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

@woile
Copy link
Member

woile commented Apr 23, 2024

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
Copy link
Member

Lee-W commented Apr 24, 2024

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

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

@woile
Copy link
Member

woile commented Apr 24, 2024

We should improve the templates to make it easier to extend

@noirbizarre
Copy link
Member Author

noirbizarre commented Apr 24, 2024

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

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
Copy link
Member

woile commented Apr 25, 2024

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
Copy link
Member

Lee-W commented Apr 29, 2024

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
Copy link
Member

Lee-W commented May 20, 2024

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
Copy link
Member

Lee-W commented May 27, 2024

#1135 (comment)

@Lee-W
Copy link
Member

Lee-W commented Aug 17, 2024

We might also want to include this one #1209

@Lee-W Lee-W changed the title Next major release ? commitizen v4 Aug 17, 2024
@Lee-W Lee-W added the v4 label Aug 17, 2024
@Lee-W
Copy link
Member

Lee-W commented Aug 22, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
issue-status: wait-for-implementation maintainers agree on the bug / feature v4
Projects
None yet
Development

No branches or pull requests

3 participants