drop php <8.2 version support

[connorhu]

1.6.x will drop the old php versions. This will help us to use modern symfony components. 1.5.x will continue support legacy php versions.

[thePanz]

When did we agreed on that strategy? :)
I see the point of removing the support of legacy PHP versions, but at the same time:

• maintaining 2 versions 1.5 and 1.6 will use a lot of time IMO
• what are we gaining by only supporting php v8.2 onward? I believe we're not going to rewrite SF1 to use attributes, match or return types not supported by php 7.4.

WDYT?

[connorhu]

Nothing is happening in 1.5.x at the moment, we are just following the latest php versions. This may remain the same, 1.5.x may be the recommended stable version.
In various issues, there has been talk for a very long time to drop the old php versions up to 7.4, but that never happened. The code is stable, regression testing works well I think, although I think lime has far fewer tools than phpunit, and it also hides bugs. This realization triggered the switch to phpunit anyway, but it also stalls if we continue to support <7.4 versions.
In 1.6.x it would be nice to get to the point where we can use modern symfony packages. The current LTS requires php >=8.1 the next LTS will require >=8.2.
My goal with this branch would be to bring some modern tools into the framework, bringing the codebase closer to modern symfony.
I'm happy to keep track of the changes coming in 1.5 so that you don't have to.

[connorhu]

I forgot to write that I want to keep the interoperability between 1.5 and 1.6. Anyone using 1.5 under 8.2 should be able to switch to 1.6 at any time without any regression and without doing anything.

[alquerci]

IMHO running behind the current Symfony is useless. The Symfony industry release a new major version faster than sf1 release a patch version.

Do you know the fable of the hare and the turtle?

But why not, without trying we can reach nothing.

---

It is easier to migrate from Symfony 2.8 to 6.4,
than from sf1 to Symfony 2.8.

Symfony 2.8 support PHP 5.3.

[thePanz]

@connorhu I see now that a PR was merged into the 1.6.x branch but not into the main one.
This might lead to confusion on which is the default branch

I would suggest the following

• keep the master branch as the default branch
• bump support for php: "^7.4 || ^8.1" into composer
• delete the 1.6.x. branch

Over Mastodon I got what you meant with the SF7 components and I see your aim, but that direction IMO should not be a new min release of SF1, but rather a "next-generation" SF1. Would it be possible to keep your aim, but have a next-gen branch which you rebase on the default master branch?

I would keep this 1.5.x release train to aim at:

1. fixing PHP 8.x warnings and deprecations
2. remove blockers for upgrading the php version for legacy projects
3. do not add new features

WDYT?

[thePanz]

@alquerci upgrading from SF1 to SF2 is impossible, what is doable is to wrap a SF1 application into a SF5|SF6|SF7 application (I am saying that by direct experience) → should we move this topic under a discussion? wdyt?

[alquerci]

to wrap a SF1 application into a SF5|SF6|SF7 application

Yes, I have the same thinking in mind.

Like I said on #201 (comment)

[connorhu]

@thePanz master is the default branch. That fork was a mistake by the guy who made the fork. And I didn't think it would occur to anybody not to fork from the default. My problem with the next-gen idea is that I can't see what happens when it's "done". What version it get. Since we are stuck between 1.x and 2.x, we don't have much leeway if we don't want to rename the project.

[thirsch]

Currently, ^1.5-dev installs 1.6.x-dev - Should we delete the branch as we are planning to stick to ^7.4 || ^8.1 for the moment?

[connorhu]

@thirsch Instead of master, we could also switch to the version branch in the 1.5.x branch. But we can delete it. :(