Behat: Say farewell to unsupported Symfony versions

[Nyholm]

This library does an amazing job supporting Symfony 2.7, 2.8 and 3.3. But some day we need to decide that it is time to stop supporting versions that has reached EOL. Keeping support for these versions will put too much maintenance work.
(I know this PR is struggling to make sure we support 4 major versions of symfony)

I suggest to only support Symfony 3.4.3 and greater.

If we not are going to decide to drop the old versions now, when is a better time?

[flug]

This pr makes backward compatibility on all versions. It works on all versions. With Scrutinizer stuff probably linked to the configuration everything works. the pr you mentioned is not finished and is duplicating mine.

[Nyholm]

@flug Dont get me wrong. You, the maintainers and other contributors do an AMAZING job maintaining all these versions. That is really appreciated.

What Im suggesting is that we make it simpler for contributors in the future by reducing complexity by removing these old versions of Symfony.

[flug]

@Nyholm I would say that the problem is more related to the roadmap, knowing which version will be which new features.
Then it's open-source so use with X version of php and X version of symfony and others. I think that in any case it is complicated anyway to not have backwards compatibility because if it came to have a flaw or something and the bc break of the new features prevents to be able to update old version it can be problematic.

Let's assume that there is a continuous delivery project and that he uses behat in the rules, it could be detrimental I think if the one if it can't be updated.
You know what I mean?

[Taluu]

Dropping support in minor versions is perfectly acceptable in semver... as long as the api of behat doesn't change.

So yes, I'd be fully in favor of dropping ols sf versions. Even PHP if I have to be honest.

(Because "Behat 4", for now, let's say there's absolutely no news whatsoever)

[rpkamp]

Let's assume that there is a continuous delivery project and that he uses behat in the rules, it could be detrimental I think if the one if it can't be updated.

But we're at the other end of the stick now. There are CD projects that want to upgrade to Symfony 5, but can't, because Behat (to be fair, amongst others) doesn't support Symfony 5 yet.

And it's not easy to support Symfony 5 because Behat also still wants to support Symfony 2, 3 and 4, and there are BC breaks between all of those. So there is a giant BC layer needed in Behat to support all of that. The pain of which is visible in the aforementioned PR.

And all of this just to support a few that won't upgrade from _unsupported_ Symfony versions? Their problems are much bigger than a build that breaks because of some Behat bug, they are at risk of having a security vulnerability in their code nobody will fix if it comes to light!
This is not something we should enable, it's something we should discourage. And we could do that by dropping support for versions of Symfony that Symfony itself doesn't support anymore.

Dropping those unsupported Symfony version means Behat can slim down the BC layer, making it easier to support Symfony 5.

[everzet]

TLDR

If BC now causes serious maintenance issues, I suggest we drop it via major version bump. If dropping BC is purely a matter of principle, I'd be more hesitant to do a jump, though I don't feel as strongly on this as on other issues.

longer version

Historically, we favoured long-tail backwards compatibility not because we had a strong opinion about it, but because it was relatively easy. The architecture and our low level of integration with language/libraries made it effortless in many cases to keep BC going. However, if that math has changed and backwards compatibility is causing serious maintenance issues, we should seriously think about dropping older versions via major version bump. I don't want to leave a portion of user-base behind, but if we lose our contributors, we will leave everyone behind.

That said, I am not as keen on the other argument of using this library as the enforcer of language/framework release cycles. I don't feel strongly about this (somewhere around 5/10), but Behat always had a clear primary objective - to help people build software in a more collaborative and descriptive way. Many of Behat newcomers are trying to apply it to their hairy legacy codebase, making it sometimes the only exit way out of the development hell. For me, the priority always was to allow people to get better with the delivery process and communication before helping them with their technical constraints. Doing BC break just because Symfony 2 is not maintained feels like a big reversal of that.

[ciaranmcnulty]

Thanks @everzet

It'd be good to have an explicit policy around this for 4.0 and onwards. We should re-introduce the PHARs (seem to be missing for some releases) and integrate php-scoper so that they can be used with older frameworks anyhow (though not older PHPs)

[Nyholm]

Very well said @everzet. I feel (with my very little knowledge about Behat) that is it complex. Just watching the struggle to support sf 5.

If we reintroduce phars with scooper then we can always use the bleeding edge versions of dependencies if we want to. I think we should follow phpunit and always recommend using phars.

[rpkamp]

I've had a stab at scoping the PHAR, but it's not easy as one might hope, because Behat is coupled quite tightly to Symfony DI when it comes to behat extensions.

See https://github.com/Behat/Behat/pull/1259

[pamil]

We're going for it, see https://github.com/Behat/Behat/issues/1296 🎉