release 3.1.0

[wd0517]

• bump to version 3.1.0
• will use pyproject.toml to publish new releases, since setup.py has been deprecated

[zhangyangyu]

how about this?

[wd0517]

I checked the Django documentation and found that for versions 4.1 and 4.2, the minimum required Python version is 3.8. For version 3.2, the minimum required Python version is 3.6.

Therefore, I will re add Python versions 3.6 ~ 3.8 into the testing pipeline for Django 3.2 only, but this may lead to longer testing periods.

In the future, I plan to create separate branches(stable/3.2.x, stable/4.1.x and stable/4.2.x similar to Django) that support for different versions of Django. This approach can simplify the complexity of DatabaseFeatures.django_test_skips and address potential code compatibility issues.

So, currently the requires-python should remain as >=3.6.

Do you have any suggestions?

[wd0517]

In the future, I plan to create separate branches(stable/3.2.x, stable/4.1.x and stable/4.2.x similar to Django) that support for different versions of Django.

Maybe I should do it now?

[zhangyangyu]

Tough question. Actually I am stumbled by the version strategy last time when I released 3.0. I investigated other Django plugins and there exists one version handles all and each version handles each. Finally I choose to use one version to handle all for ease. I remember the 3.6 is chosen due to Django 3.2 at that time. #19 (comment)

I don't have a strong opinion on this. At that time I just thought it seems easier for users and there is not much difference, so releasing several versions looks cumbersome.

[wd0517]

I will choose each handles each, for the following reasons:

• Django may introduce breaking changes in the future: currently it's one for all, when I commit a new feature, I need to consider 3 Django versions of the code, thankfully, now the breaking changes exist only in tests, so there are so many code need to check skip tests by version (https://github.com/pingcap/django-tidb/blob/main/django_tidb/features.py#L272-L429), it's obviously ugly, but if Django introduce breaking change in db module for some reason in future, the code will be more confusing and even impossible to maintain.
• Simplify test pipeline: different versions of Django have different Python support list, which can complicate the testing pipeline. Additionally, GitHub Actions has a limit of 20 concurrent jobs, but we currently have 27 jobs running. This results in a testing task that takes about two hours and provides a poorer experience. (Reducing the time for each individual test is also necessary in the future)
• Deliver a more clearly pyproject.toml

Each for each version strategy:

The minor release number of Django doesn't correspond to the minor release number of django-tidb. Use the latest minor release of each.

django-tidb	Django
v3.2.*	v3.2.*
v4.1.*	v4.1.*
v4.2.*	v4.2.*

User Perspective: Users should use the version of django-tidb that matches their Django version.