FriendsOfSymfony1 organization what next?

[alquerci]

Hello folks,

At the end of the discussion of the issue #102 symfony1 and doctrine1 has been moved to the organization.

Now the organization have to grow in order to be useful for the community.

Questions

Was there a decision made about who has commit access?

I was tagged in #200 with a request to review, and I'm happy to do so, but I do not have commit access.

Originally posted by @mkopinsky in #102 (comment)

@mkopinsky We may use the same policy as the Symfony Core Team.

In any cases the code review can be done by everyone and this can help a lot the mergers.

@fabpot Do you have any recommendations?

Originally posted by @alquerci in #102 (comment)

I suggest this to-do list.

• Send invitation with pull access to everyone who want to be part of the organization
  • Everyone who written a message on Friends of Symfony1 (FOS1) Organization? #102 is a good start.
• Create a team with all members in order to be able to start discussions about projects of the organization.
• Choose at least one merger per repository who is able to merge pull requests at least one time per week.
• Add a logo for the organization (who cares 😄)

I suggest its rules

• The code review we may use the Pull Request Voting Policy
  • While new features of GitHub help a lot for this.
• For the Pull Request Merging Policy
  • Enough time was given for peer reviews (at least 1 week for "regular" pull requests, and 1 month for pull requests with "a significant impact");

Anyway, rules or other things are open for discussion.

cc @thePanz

---

Summary of comments

⚠️ Following elements are not a consensus but just a formatting. I do my best in order to be the more objective as possible, I am just a human who can make mistakes.

The "HOW" is less important than the mission or goals which may changed.

The mission of FriendsOfSymfony1 organization

Provide trust until the obsolescence of the symfony1 ecosystem libraries, where libraries are no more used.

Maintainers of symfony1 ecosystem libraries are not alone.

Goals

• Gather a maximum of feedbacks from maintainers of symfony1 ecosystem libraries

  Is there a way to survey people?

• Projects using symfony1 are secure

  people are just looking for security patches and new PHP versions compatibility to keep their legacy running

  I think compatibility with recent php versions

  • Security support
    • Support maintained PHP versions while still supporting PHP 5.3
    • Accept security patches
  • Full back-compatible, project maintainers SHOULD be confident to upgrade to the latest version

[e1himself]

In regards to existence of the FOS1 organisation, I believe the most important is to define the mission and the goals.

Naming a few that come into my mind:

• Minimal support: accept security patches only
• Compatibility support: accept security patches and maintain compatibility with new PHP versions as they are released
• Full BC without new language features (i.e. keeping PHP 5.3 support)
• Full BC with new language features (for projects with rolling update strategy). Means adopting return-types (PHP 7.3), for example
• Full framework support, including developing new features

Once the goals are set, only then it makes sense to talk about the rest.

[alquerci]

Hello there,

For your information we have a dedicated Slack channel on symfony-devs.
Check-out the Slack on https://symfony.com/community

The name of the channel is friendsofsymfony1.

Anyone are welcome to join the channel.

[alquerci]

We must keep in mind that this framework is deprecated.

This include doctrine1 and all sf*Plugin.

IMHO we should focus on following goals:

• No back compatibility breaks to be compliant with semantic versioning.
• Bug fixes (this include compatibility with latest PHP version)
• Security fixes
• Provide the most easier migration path to the latest Symfony version.
  • The first action: add ability to use the latest Symfony DIC version.
  • Write a migration path documentation.

[e1himself]

Good stuff 👍

• Provide the most easier migration path to the latest Symfony version.
  • Write a migration path documentation.

However, I don't think it is feasible to move the fork closer to Symfony 2+ and keep backwards compatibility at the same time.

I have a similar goal in mind by slowly moving forward another fork of this fork: https://github.com/rock-symphony/rock-symphony
Not aiming for the latest Symfony though, but just to build on top of PSR-based components.

Just to say, the fork is at version 5.x already (meaning it had 4 BC breaking releases already). That's why I have a solid confidence that it's not realistic to have full BC and move it closer to the latest Symfony.

[alquerci]

@e1himself

However, I don't think it is feasible to move the fork closer to Symfony 2+ and keep backwards compatibility at the same time.

The goal will not to add all features of Symfony2+ but just provide a migration path documentation and maybe on another repository a bunch of classes that will help to:

• Create a Symfony2+ Request from a sfRequest.
• A sfTwigView
• A way to migrate routes configuration
• and much more.

The most important is to help to follow best practices as remove all business logic on controllers and templates and move it to Symfony2+ DIC. That has already been done in one of my projects.

Regarding Symfony naming it will be named bridge.

[e1himself]

I'm not sure how many people really want to spend time on their sf1 projects and upgrade/migrate those projects to a new Symfony version. Most probably people are just looking for security patches and new PHP versions compatibility to keep their legacy running.

Is there a way to survey people?

[alquerci]

Most probably people are just looking for security patches and new PHP versions compatibility to keep their legacy running.

Maybe but a deprecated framework can not have an infinite maintenance period, this is not realistic.

Think that Symfony2 have currently no bug fixes and security patches period ends this year.

The most important thing that make legacy projects stuck on sf1 is that the migration cost is currently too high.

[thirsch]

Well, I think compatibility with recent php versions might be the number one goal of everyone who is looking into this repo. It's not so much to get any new features here.

As already said, bigger legacy projects will probably never migrate to a modern Symfony, because of the migration cost. I can only speak for what we try to do: As it has become common to not build monolitic monsters anymore, we try to build small microservices to solve different tasks and on that way, we are trying to remove piece by piece from our big sf1 project.

Any news on maintainers? There are a few good prs waiting to be merged.

[alquerci]

ℹ️ I had just add "Summary of comments" section to the description of this issue.

Any feedbacks are welcome.

[connorhu]

I found it last year and thought about what @thirsch wrote and it discouraged me a bit from doing anything forward thinking here. I'm sure many people are looking for this rep to just get support for new php versions and nothing more.

While I was porting the test system to PHPUnit I had a strong feeling that it's not that far away from each other, you can get to the point where you can have symfony7 components running in the background (e.g.: util folder some classes, finder, yaml parser, event dispatcher etc).

Then I realised that I do have a goal to not only keep alive the code of my two clients, but to eventually get the codebase to modern basics. Those codes aren't monolithic monsters, they're a predictable codebase, but the client doesn't want to invest the money to rewrite from scratch. If my work is not affordable in a closed source environment, I'd be happy to do something that benefits the community.

With symfony7's component approach I feel that it is possible to move the codebase forward, even keeping the no-breaking-change promise (1.5.x only php version tracking, 1.6.x major improvements).

With current analyzer tools, with symfony7's deprecation gathering approach, there are many tools that could be put in the hands of developers that would not leave them alone in tracking changes. Since I have two, not very large systems based on symfony1, I can test them on working systems all the time.

If drupal can benefit from symfony components I think we can too.

Would it really be nice to know who is using this code base and what their purpose is?

WDYT?™

[ingcarlosperez]

Hi @connorhu , I've been working with Sf1 for about 13 years and have a huge project with this framework. I encountered the same problem when transitioning to the Sf2 version. With a lot of code, I didn't have time to migrate my base code to the new version.

Hopefully, the FriendsOfSymfony1 community will come to the rescue with this fork. Currently, I haven't finished testing this version, but the results are OK for me at the moment.

In this scenario, I had the same question you have. My approach was to reorganize my ProjectConfiguration.class.php to include a new autoload.php for requiring new PHP components in my code.

I've been testing new libraries to replace some functions in my code (email, PDF generation, etc.), and at the moment everything looks good.

At the end of the day, I want to maintain the Sf1 route system, the generators (admin and modules), and the configuration approach. I expect to replace other tools with modern components.

If you'd like to see some of these changes, please let me know.

[alquerci]

With a lot of code, I didn't have time to migrate my base code to the new version.

5 years ago, I had a dream.

./symfony project:migrate-to-version-4

Today, this dream still exists.

Does someone share the same dream?

[sbrowett]

Same guys, and glad I'm not the *only* person on earth still stuck in this pleasant but ageing hole! Too big to migrate, still works great, but getting left behind! Where's the magic wand when we need it?!

…

On Mon, 8 Jan 2024 at 19:13, Alexandre Quercia ***@***.***> wrote: With a lot of code, I didn't have time to migrate my base code to the new version. 5 years ago, I had a dream. ./symfony project:migrate-to-version-4 Today, this dream still exists. Does someone share the same dream? — Reply to this email directly, view it on GitHub <#201 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAVBTEID77NEYM2I5X3VGKTYNRAL5AVCNFSM4GC6TBIKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBYGE3DONJRGU4A> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

-- Regards, Steve Browett ***@***.*** 07985 417870