build(python): Sunset Python 3.6 and support Python 3.11

[noirbizarre]

Description

Proposal: This PR sunsets Python 3.6 and adds supports Python 3.11 given Python 3.6 is been sunsetted 1 year ago and lately buils are not running anymore on Python 3.6 (see https://github.com/commitizen-tools/commitizen/pull/631/checks as example).

BREAKING CHANGE: Python 3.6 is not supported anymore

Checklist

• Add test cases to all the changes you introduce
• Run ./scripts/format and ./scripts/test locally to ensure this change passes linter check and test
• Test the changes on the local machine manually
• Update the documentation for the changes

Expected behavior

New package don't advertise support for Python 3.6 anymore
CI stop running on Python 3.6
Python 3.11 support is now tested in CI
CI is green again

Additional context

Fixes #607

I permitted myself to submit this PR because builds are now failing on Python 3.6 for new PR like mine: #632

[noirbizarre]

Build is failing due to exceptiongroup being pulled in dependencies by pytest.
I don't know how you want to handle that so I am waiting for your input on this.

By the way, I was surprised the poetry.lock file is not commited in the repository. Is there a specific reason why ?

[woile]

Hey thanks a lot for this PR. I'm not sure why is the CI failing tbh.
I'm thinking maybe this could be part of your other PR, so we can have just a single breaking change. What do you think?

By the way, I was surprised the poetry.lock file is not commited in the repository. Is there a specific reason why ?

My understanding (might be outdated), is that locks are for deployable applications (like an app). Without a lock file, you may get into issues (because semver is not perfect, right? a new feature in another library may break us). This means that contributors of this projects may get into trouble, allowing us to fix the problem. In short, is another way for us to find problems. Does it make sense?

[noirbizarre]

Yes, I think another PR is required just to fix the CI (I will try to have a look tonight, seems related to the exceptiongroup monkeypatching.

For the lock file, I think it would solve the dev/test env stability part. For the library publication, I think this is depending on how the it done by poetry: either it is packaging the dependencies as expressed in pyproject.toml andthere shouldn't be any issue, either it is pinning dependencies to their locked version and it would justify not having the lock file.
I will take a look and probably have a PR for that but I think this is the first case.

[codecov]

Codecov Report

Base: 97.92% // Head: 98.36% // Increases project coverage by +0.44% 🎉

Coverage data is based on head (dd2a887) compared to base (db42a95).
Patch coverage: 83.33% of modified lines in pull request are covered.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #633      +/-   ##
==========================================
+ Coverage   97.92%   98.36%   +0.44%     
==========================================
  Files          35       39       +4     
  Lines        1252     1655     +403     
==========================================
+ Hits         1226     1628     +402     
- Misses         26       27       +1     

Flag	Coverage Δ
unittests	98.36% <83.33%> (+0.44%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
commitizen/cli.py	94.11% <75.00%> (+0.17%)	⬆️
commitizen/__version__.py	100.00% <100.00%> (ø)
commitizen/commands/changelog.py	98.86% <100.00%> (ø)
commitizen/bump.py	100.00% <0.00%> (ø)
commitizen/changelog.py	99.43% <0.00%> (ø)
commitizen/exceptions.py	100.00% <0.00%> (ø)
commitizen/__init__.py	100.00% <0.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

[noirbizarre]

I integrated #634 in this one as multiple fixes were needed to make the CI green again:

• removes the not support anymore Python 3.6 jobs
• ensure build are reproducibles by commiting the poetry.lock
• upgrade some dependencies (basically pytest plugins and black
• fix the failing tests (side-effects of pytest upgrades)

I didn't touch the dependencies that where not requiring an upgrade (can be done there or in another PR, as you want).

I added a dependabot.yml configuration to receive pull requests updating workflows and poetry.lock ensuring we test and discover new versions issues as soon as they are available.

This should fix the CI ✅ and makes it more resilient to future dependencies update by not staking them.

[noirbizarre]

@woile Build is passing with those changes and result in clean reproducibles builds as well as Python 3.6 drop and 3.11 support.
Failing tests have been fixed and CI is green.
Is it OK for you ?

[Lee-W]

@woile I'm good with these changes and plan to merge it these days. Let me know if there's anything you want to check again :)

[woile]

I'm good with it. But I'm just wondering if we want to have this, and then the new plugin system creating multiple Major versions. We'd be at commitizen v4 at that point 😅 I guess I have to break my sentimental attachment to Major versions 🤣

[noirbizarre]

Isn't it possible to have a single version with multiple breaking changes ? To me it is not an issue and totally compliant with conventional commit but maybe I am missing a specific policy on this repository.

But it you want to start staking breaking changes maybe there needs to be a 3.x branch we can target. But here there is 2 things: fixing the CI which seems required and introduce a mandatory breaking change and the plugin system which can be staked for a 3.x. I can change the target branch a for the extension system if we create a branch after this merge

BTW: PR updated/rebased on the latest master.

[woile]

You can stake them yes, but we don't have any policies in this repo. Normally I would create a new branch for breaking changes, and send everything there, like you suggest. But for this case, it might make sense, v3 to drop 3.6, and v4 for the new plugin system. @Lee-W ?

[woile]

Only thing, I would update this commit:

- BREAKING CHANGE: Python 3.6 is not supported anymore
+ BREAKING CHANGE: Python 3.6 is not officially supported anymore. Please migrate from 3.6 to 3.7 or greater.

[noirbizarre]

👆🏼 Updated 👍🏼

[noirbizarre]

Note: I have multiple PRs to submit, some to discuss... 😅
So having a 3.x with updated deps and python support, new extension system + a bunch of other features could be great Major !
(From a lib/cli consumer point of view, I prefer a single release with 3 breaking changes to handle than 3 consecutives releases with breaking changes, it is easier to understand, there is one before and one after, no intermediate states to support)

[Lee-W]

I'm actually good with either way. But if we're planning to merge a few breaking changes in a short period, v3 branch might be a better approach.

[noirbizarre]

Good to me 👍🏼
As soon as this PR is merged and the v3 branch (or whatever the branch is named) is created I'll dispatch the PRs on main for non breaking changes and on v3 for the breaking ones or those depending on it 👌🏼

[Lee-W]

I just created a v3 branch. Let me merge it to that branch first 👍