Support Symfony 6 in 1.x

[japerry]

Drupal 10 is coming later this year, and as @Berdir has described in #1675 (comment) -- getting Symfony 6 into 2.x (or at least 2.0.0) is not an option due to 7.4 being the minimum.

Looking at how the 1.x branch has progressed, it seems PHP versions have increased over the years. Seeing as the Drupal module implements the 1.x branch (requiring 1.19 as of this issue), could we have the 1.20 branch increase the minimum version of PHP to 8.0 to add Symfony 6 support?

[tvdijen]

No. The 1.x branch is stale and is not being developed anymore. There is simply no developer capacity to work on everything.
2.0 is in RC-state and is not receiving any major changes anymore.
Your best shot is to wait for a future 2.1 release.

[japerry]

While I understand the intention was for the 1.19.6 release to be the last, even within that branch there has been commits, and probably should be a 1.19.7. Unless I'm mistaken, the 2.x branch is not necessarily backwards compatible with 1.x configurations, which means users and integrations (CMS modules/plugins) like have to manually intervene.

If 2.0 had been out for a while, I might agree that this issue isn't needed. However, that is not the case. 2.0 is not even stable yet, which means its practically premature to say support has ended for the 1.x branch. And even if 2.0 is out (or comes out this week), its not enough time for users to migrate over. Making users upgrade to 2.1 (which doesn't even have a branch yet, let alone a release or beta) so they can work with newer versions of Symfony that are already out is unreasonable IMHO.

As a maintainer of the simpleSAMLauth_php module for Drupal, that leaves me at a crossroads: Either convince you guys to make a 1.20 branch that contains the relatively simple symfony 6 compatibility change or we make a fork that creates a 1.20 release branch with the change. Then when the 2.1 branch is stable, we release a new corresponding Drupal module major as well to support the 2.x changes, eventually dropping our 1.x drupal module and corresponding 1.20 fork. This is much less desirable, so I hope that we can move forward with a minimally maintained 1.20 branch on the mainline project.

[thijskh]

There will likely be further maintenance releases on 1.19.x while 2.0 is not yet fully stable, but it's unlikely we will be creating new feature releases on 1.20 since we as a project do not have the person power to sustain this.

Drupal 10 is also not released yet, fwiw.

You are indeed welcome to support Symfony 6 in a fork, no hard feelings, and I'm sure we will support it in 2.1.

[tvdijen]

We've discussed this once more internally and we stick to our point. Our primary focus is to release 2.0, because that has been taking forever.
From that point on, we will strictly follow SemVer and we have no problem releasing 2.1 or even 3.0 shortly after. We just can't keep expanding the scope for our 2.0 release, or it will never see light (1.x exists for 15 yrs and we really have to say goodbye to the amount of legacy code that has grown over this period)..

That being said; Symfony 5.4 is the current LTS and has support until the end of 2025... 6.0 was only released last november and with the current rate they're farting out new releases, no one can keep up unless it's your day-job. We also look at what the major releases currently support and Debian (stable), for instance, supports PHP 7.4 and there is no known date for a new stable... You are, -briefly-. ahead of your time.. Which is fine, but our world (T&I) tends to move a little more conservative.

[kreynen]

Maybe we can step back and ask/approach this a different way? I may have inadvertently created some conflict opening with https://www.drupal.org/project/simplesamlphp_auth/issues/3306294. I noted that we needed the watch the fact that this project was looking for a lead developer a few ago in cu-uis/cu-starterkit-project#1 (comment)

I absolutely hear you when you say "we just can't keep expanding the scope for our 2.0 release".

Temporarily forking is obviously an option, but that isn't going to be something the security teams at large universities will be excited about.

Would it help to reframe this by asking, what would it take to manage a version of the library that worked with Symfony 6/PHP8.1 (Drupal 10's requirements)?

Is there a certain amount of of $$ that would allow developers with the necessary skills to dedicate more time to the project? If we were able to raise that from large organizations that depend on this library, are there people available to do the work.

I'm jealous of organizations like John Hopkins with a FOSS Fund already set up to contribute to the projects they depend on, but in this case it seems like the work that needs to be done is clear enough that I can see being able to raise the $$ required... assuming there is a way to translate the $$ into work. I think I would be able to make the case to the University of Colorado about why we needed to contribute if we want this to move forward.

If I'm being really naive about the work required, PLEASE let me know.

[tvdijen]

I think we found the developer, although I should verify this with our board members (@jaimeperez). They have been busy over the last few months to raise funds and get us settled at the NLNet foundation.. Of course any donation would be more than welcome.

The security teams you mention will also not be happy with early adoption of any piece of software, especially when it comes to authentication software.. Nor PHP 8.1, nor Symfony 6 is going to improve your security.. Any claim in this direction will fall short.

The consideration we constantly have to make is whether to move on or not. If we move the fast, we lose our more conservative (like Debian) user-base, if we move too slow we may lose connection with the more progressive projects like Drupal.. Keeping multiple versions alive is hard given the number of resources we have.

[jaimeperez]

Hi!

Thanks Tim for invoking me 😅

The SimpleSAMLphp project definitely needs resources, whether those take the form of a helping hand or a monetary contribution. Still, since I stepped aside as maintainer of the project we've been looking for someone to take over that role, and for that we definitely need funds, not only as a one-time contribution, but more or less continuous in time. So in that sense, any help we could get to raise those funds and be able to pay a person to properly maintain the software is very much appreciated.

At the moment we're surviving basically thanks to the invaluable work of Tim and Thijs, but that is not sustainable. We can just focus on addressing bugs, security issues, and slowly finishing the work of many years towards 2.0. Without any more resources, I don't think we can consider supporting two stable branches at the same time, or bringing our dependencies to bleeding edge, unfortunately.

[kreynen]

Maybe I'm just missing it, but how does a person or organization donate specifically to the simpleSAMLphp project? I saw https://nlnet.nl/ mentioned earlier, but we just give to one of the larger theme funds? I searched for donate on https://simplesamlphp.org/ and got 0 results. It doesn't look like you are using https://getcomposer.org/doc/04-schema.md#funding yet.

Defining and sharing the recommended process for donating might belong a different queue. If you do open a different issue, please ping me. Keep in mind that for those of us working at larger, government/government adjacent organizations, saying that I gave money to random people on the internet for "stuff" often isn't enough to justify the expense. We don't need to a full detail of how the $$ gets spent, but I need to be able to document that money donated to https://nlnet.nl/ goes to support a project we depend on.

THANK YOU!

[Berdir]

While I don't necessarily agree with your plan on supporting PHP 7.4 on 2.0, I understand and respect that. I've outlined my plan what that means for the Drupal integration here: https://www.drupal.org/project/simplesamlphp_auth/issues/3306294#comment-14674065.

I as you can see, I disagree with @japerry on that front, his comments are IMHO factually wrong (It's not easy to support Symfony 6 for 1.x at all. It would be easy to support it from a technical perspective in 2.0, but it's not about the technical changes, it's about what kind of PHP versions you want to support there).

This issue has been closed, lets move the discussion on supporting/donating to this project elsewhere.

the more progressive projects like Drupal.

That's not something you usually hear when talking about Drupal, but I guess it's all relative :)

PS: Thanks again for the very fast reviews and feedback on my Symfony 6 merge requests, while the situation with dev-master is not ideal, it at least gives us a feasible way to test the integration on Drupal 10/Symfony 6 and have early adopters move there.

[tvdijen]

the more progressive projects like Drupal.

That's not something you usually hear when talking about Drupal, but I guess it's all relative :)

That's exactly my point... My guess is that you @Berdir @kreynen and @japerry are all developers that want to use the newest features.. I can understand that to an extent, but there's legacy to deal with..

While I don't necessarily agree with your plan on supporting PHP 7.4 on 2.0

What would you do in our case? Kill the entire Debian community? Honest question.
We know our community.. We meet face-to-face with them on a regular basis..

[Berdir]

We know our community.. We meet face-to-face with them on a regular basis..

Yes, that is my assumption. Which is why I can't speak for your community/users, only for my "world" of web application development:

What would you do in our case? Kill the entire Debian community? Honest question.

There has been a big shift in the PHP world (like most others) to have more flexible PaaS/container-based hosting where you can pick your PHP version freely and it's not tied to whatever version your OS happens to ship. platform.sh in our case but there are a bunch of big providers in the Drupal/PHP space as well as doing it yourself with docker/kubernetes/whatever. The PHP team has also considerably tightened their schedule, with previous versions being supported for a shorter time than in the past. And big frameworks tend to require recent PHP versions quicker than in the past, with obvious exceptions like Wordpress.

And even with native debian hosting, https://deb.sury.org/ has provided a reliable source (so far) for more recent PHP versions for a long time now.

As someone posted in the original Symfony 6 issue (#1588 (comment)), the security support for shipped versions is pretty limited and especially in a security-critical environment, I'd recommend against using that.

[github-actions]

\n This issue has been automatically locked since there has \n not been any recent activity after it was closed.\n Please open a new issue for related bugs.