We have started work towards a 4.0.0 release.

We'd hoped to start a new major for a while (there has not been a major release since 3.0.0 in 2014). However the primary motivation for doing this now is that symfony 8.0 incudes BC breaks in the symfony interfaces we extend. Therefore, we cannot support symfony >= 8.0 with Behat 3.x, and this is holding back users who want to upgrade to the newer symfony version.

Therefore the goals for 4.0 are:

• To stick to a scope that allows us to deliver a release relatively soon, even if there are other breaking changes we want to make in future.
• To make it as easy as possible for extension authors to update to 4.0 - most packages should be able to update primarily using automated tooling (e.g. Rector) although some manual changes may also be required.
• To make it as easy as possible for end-users to update to 4.0 - the majority of users should only need to bump their dependency constraints, and perhaps run automated tooling that we provide to update their projects.
• As much as we can within the constraints above, to take the opportunity to make other breaking changes (primarily dropping deprecated features and code and support for edge cases and unexpected usage), to make it easier to work towards subsequent 4.x releases and an eventual v5.

Ensuring that 4.0 is a frictionless update for extensions and end-users is important, because it will allow us to set a relatively short EOL for 3.x. That minimises the overhead of maintaining multiple versions in parallel, particularly when we want to start working on v5.

I propose that we split this into (at least) two releases:

4.0.0-alpha1

This will be an "essentially stable" alpha containing all the planned breaking changes that are likely to affect extension authors (strict types, formally marking some classes as @internal, etc).

4.0.0-alpha1 should also be stable enough for end-users to run in CI.

This will provide:

• A clear base for extension authors to update their own code.
• A chance for us to respond to feedback (e.g. unexpected challenges upgrading) before things are locked down.
• Slightly less time pressure to complete everything that we want to get into 4.0 - users who are keen to bump to symfony8 should be able to start using 4.0.0-alpha1 as soon as we release it.

4.0.0

Breaking changes that are unlikely to directly affect extension authors or expected usage, or that remove deprecated functionality, do not need to be prioritised for alpha1.

These can wait and be shipped before the final 4.0.0 release - so long as users know what's coming, they should be able to update their projects against alpha1 before we actually complete all the deletions / internal refactoring.