Reduce number of maintained migrations and change versioning

[nijel]

Describe the problem

Currently we maintain migration support within a major version. This would work quite well when we regularly release a new major release. But with more continuous development, there is really no reason to bump the major version (besides wanting to get rid of ancient database migrations). Presently, migrating from Weblate 5.0, released in August 2023, is still supported. I'd like to reduce this window.

Solution brainstorm

• Use year-based release numbers. Users will directly see how old their version is :-). See https://calver.org/
• Support database migrations from the previous year. The first release in a new year drops support for the year before.

Describe alternatives you have considered

We might also only change the migrations policy, but it will be harder to explain when no longer bound to the version.

Screenshots

No response

Additional context

No response

[gersona]

The year based release number might be a bit confusing at first but is a reasonable option, and I think good for long term:

• It will make communication more explicit about migrations support policy (e.g: it's clearer for users when we say "migration support is limited to v26.0" than "migration support is limited to 16.5.1 (December 2025)"
• It also frees us from waiting for important changes before releasing a major version (which are less common as the project grows in maturity)

[nijel]

With the recent influx of security issues to both Weblate and our dependencies, we need a more frequent release cycle as well.

So let's switch to calver: ..

Release at the beginning of the month (there will be a transition to this; see current plan at https://github.com/WeblateOrg/weblate/milestones).

I'm also thinking of exactly pinning Python dependencies here instead of supporting ranges. The ranges are anyway becoming pretty narrow with the security updates across the ecosystem. This might force us to do a release just because of a security issue in a dependency, but this would give users a more controlled way to get such updates.

@WeblateOrg/developers I need your feedback here.

[KarenKonou]

Calver sounds good to me, I like the human readable version numbers, I don't really have much experience with python deps so I don't have much to say there.