Hypothesis: Planning our next major version increment

[Zac-HD]

For the last few years, we've released a new major-version in early January, using it to clear out our deprecations and notably to drop Python 2 (🎉). This issue is to invite discussion, from @HypothesisWorks/hypothesis-python-contributors and anyone interested in the wider community, about both our next major version and our policy around them.

The next major version will remove or alter seven deprecated APIs, and change the calling convention of a further 46 functions to use keyword-only arguments (via @deprecated_posargs). In all cases these were either silently broken, or are older than our six-month minimum deprecation period and can therefore be removed. However, I would like to ship codemods to automate the update (#2705) for at least the kwonly args change before converting them to a hard error; likely meaning later in January.

I like our major version policy, even if semver under-specifies "breaking change" (I think we take this more seriously than many other libraries I use). An annual release cadence does suggest that calver might be a better choice, so I propose that we use pip-style "YY.minor.micro" versioning. Specifically, we would release version 21.0.0, remain semver-compliant, and clearly communicate age in libyears rather than giving an impression of API instability.

Thoughts?

[sobolevn]

Hi!

An annual release cadence does suggest that calver might be a better choice, so I propose that we use pip-style "YY.minor.micro" versioning.

I have some experience with calver as both user and maintainer and I want to share it.

The thing with An annual release cadence does suggest that calver might be a better choice is that this just happens to be the case right now and can be changed in the future.

Moreover, it has some clear disadvantages:

• Switching to calver will not allow us to ship a breaking change in the middle of the year even if we need to.
• The release cycle might also be larger than just one year. For example, there might be a year without a major release. This will leave users with an impression of using an outdated library. Like using 22.1.0 in 2024. pipenv is the most canonical example here.

What is even more important is that switching to calver is not something that can be easily undone.

In my opinion, calver is a great thing for libraries like pytz or security-related ones or any other libs that need to indicate when they were released. Which is not the case for hypothesis IMHO.

Anyway, thanks for the opportunity to discuss it publicly! 👍

P.S. Happy holidays! 🎅