Proposal: Planning for 4.2 and 5.0 Releases

[alanverresen]

Version 4.1.0 of django-recaptcha was released on March 28, 2025. Since then, some minor changes and one long-requested feature (#226, #382) have been added, so I think it would be nice to release version 4.2.0 in the near future. There is also a bunch of stuff in the pipeline that is likely to break backwards compatibility in some way. With this in mind, I would like to propose the following release plan for the near future.

First, I would like to resolve the issues/PRs that do not introduce any breaking changes or new features before shipping version 4.2.0. I've identified the following as potential candidates:

• Missing required parameters: sitekey #160
• Recaptcha V3 fails to validate #199
• Add Python 3.14 and Django 6.0 to test matrix #376
• recaptcha_test_key_error: accept the test keys if DEBUG is True #381

I also propose to split up development into two different branches, after some or all of the issues/PRs listed above have been fixed:

• use the main branch to develop version 5.0.0
• use a branch dedicated to 4.2.X releases to develop any fixes if needed

By jumping up to version 5.0.0, we can communicate a clear break in backwards compatibility. This is necessary, because changes like #336 are likely to cause unforeseen consequences. This would also be a great opportunity to address other outstanding issues/PRs like #276 and #277 again and to clean up the package where deemed necessary, without having to be afraid of breaking existing installations.

What does everyone think (but especially @Stormheg @thibaudcolas)?

[Stormheg]

Thank you for taking the initiative planning this Alan, I've created two milestones in GitHub and earmarked the issues with what release we plan to ship them. Makes for an easier overview. Let's go with your suggestions and prepare a 4.2.0 release 'soon' - not naming a date because I don't want to commit and set a deadline for volunteer work.

As for your proposal to split development into branches, I think this requires us agreeing on a support policy for old releases. My stance on this is: unless there is a major security issue and asking our users to just upgrade is not reasonable, I am not going to bother making additional releases for older versions or create stable/5.0.x branches during the release process. This increases the work needed to make releases and I am not keen on doing that.

(if my take happens to become our policy, we should document that clearly, in the readme for example)

---

As for 5.0.0, I agree that #336 is likely going to be disruptive for people who have overridden templates to work around some issue so a new major release containing breaking changes makes sense to me. Have added it to the 5.0.0 milestone.