commitizen v4 #1073

Activity

1. noirbizarre

   added

   issue-status: wait-for-implementationmaintainers agree on the bug / featuremaintainers agree on the bug / feature

   on Apr 18, 2024
2. github-actions

   added

   issue-status: needs-triage

   on Apr 18, 2024
3. Lee-W

   removed

   issue-status: needs-triage

   on Apr 21, 2024
4. Lee-W commented on Apr 21, 2024

   

   Lee-W

   on Apr 21, 2024

   Member

   More actions

   Not sure whether we need to create a 4.0 branch 🤔
5. Lee-W commented on Apr 23, 2024

   

   Lee-W

   on Apr 23, 2024

   Member

   More actions

   I'm thinking of splitting version_schemes into smaller modules. Make both version_schemes and providers pluggable
6. woile commented on Apr 23, 2024

   

   woile

   on Apr 23, 2024

   Last edited by woile

   Member

   More actions

   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?
7. Lee-W commented on Apr 24, 2024

   

   Lee-W

   on Apr 24, 2024

   Member

   More actions

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

   ah, you're right. I forget it 🤦‍♂️
8. woile commented on Apr 24, 2024

   

   woile

   on Apr 24, 2024

   Member

   More actions

   We should improve the templates to make it easier to extend
9. noirbizarre commented on Apr 24, 2024

   

   noirbizarre

   on Apr 24, 2024

   Last edited by noirbizarre

   MemberAuthor

   More actions

   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: 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:
     • 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.

   👍React with 👍2Reacted by Santiago Fraire Willemoes and Wei Lee
10. woile commented on Apr 25, 2024

    

    woile

    on Apr 25, 2024

    Member

    More actions

    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

    👍React with 👍1Reacted by Wei Lee
11. Lee-W commented on Apr 29, 2024

    

    Lee-W

    on Apr 29, 2024

    Member

    More actions

    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
12. Lee-W commented on May 20, 2024

    

    Lee-W

    on May 20, 2024

    Member

    More actions

    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
13. Lee-W commented on May 27, 2024

    

    Lee-W

    on May 27, 2024

    Member

    More actions

    #1135 (comment)
14. Lee-W commented on Aug 17, 2024

    

    Lee-W

    on Aug 17, 2024

    Member

    More actions

    We might also want to include this one #1209
15. Lee-W

    changed the title [-]Next major release ?[/-] [+]commitizen v4[/+] on Aug 17, 2024
16. Lee-W

    added

    v4

    on Aug 17, 2024
17. Lee-W commented on Aug 22, 2024

    

    Lee-W

    on Aug 22, 2024

    Last edited by Lee-W

    Member

    More actions

    @noirbizarre I just created a v4 branch. Also added some branch protection rule to this branch
18. Lee-W commented on May 31, 2025

    

    Lee-W

    on May 31, 2025

    Member

    More actions

    close this in favor of #1481. it's almost one year since the last discussion, probably worth rethink what we want to have
19. Lee-W

    closed this as completedon May 31, 2025