FriendsOfSymfony1 organization what next? #201

alquerci · 2018-11-09T23:03:13Z

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 · 2019-08-27T15:17:50Z

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 · 2019-08-27T19:16:54Z

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 · 2019-08-27T19:47:07Z

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 · 2019-08-28T08:42:29Z

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 · 2019-08-31T18:50:55Z

@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 · 2019-09-02T08:26:16Z

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 · 2019-09-03T19:36:59Z

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 · 2021-03-23T16:06:42Z

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 · 2021-03-25T00:48:04Z

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

Any feedbacks are welcome.

connorhu · 2024-01-08T12:37:09Z

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 · 2024-01-08T17:26:00Z

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 · 2024-01-08T19:12:47Z

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 · 2024-01-08T22:52:55Z

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

e1himself · 2024-01-09T12:38:19Z

./symfony project:migrate-to-version-4
Does someone share the same dream?

Nope.

Not realistic, even for a dream, IMO :)

alquerci · 2024-01-09T19:03:45Z

Who has able to predict in 2018 that sf1 and doctrine1 be compatible with PHP 8.3?

We made it!

Let's target Mars, at least we can reach the Moon.

Now we can think about things a bit more interesting, like @connorhu said:

benefit from symfony components

Behind that thinking, sf1 may become a bridge to Symfony components like Laravel.
Later, the bridge can be dropped.

e1himself · 2024-01-09T21:35:28Z

not the only person on earth still stuck in this pleasant but ageing hole

Just to share:

We are still successfully running our project (being under active development of new features all these years) on a symfony1 fork (with some amount of incremental updates, including PHP 8.3 support), plus several new components added at the application level: SQS command bus integration, Laravel-inspired service container, new authentication layer and request data validators.

Though the app has evolved over the years into becoming a REST API backend mostly, with almost no responsibilities over rendering any HTML templates or forms -- it's all React in the frontend. So we only use the (stock) HTTP kernel and middleware logic (aka filters), with homebrew request validators, and our own service container. Keeping the app binding to the framework as minimal as possible, with the hope to replace the HTTP kernel with a PSR-based standalone (non-framework) library some day in the future.

Ah, and Propel. But there's no visible path to replace it with anything else at any time in the future :)

e1himself · 2024-01-09T21:42:50Z

Who has able to predict in 2018 that sf1 and doctrine1 be compatible with PHP 8.3?

Or better to mention January 2010 (14 years ago! 🙀) -- the official EOL date of the symfony1 framework :)

mentalstring · 2024-01-10T22:12:57Z

Like some of you here, I have an active, large-ish project built on top of symfony1 that is too hard to rewrite from scratch on something else. Hence, I'm happy that FOS1 exists and has been helping support new PHP versions, and even the composer support has been quite helpful (thank you all 💙). Meanwhile, I've been trying to use Symfony components wherever I can to avoid building more on top of the legacy code, but things like routing, authentication and orm (anyone else still on propel1?) are hard to move away from.

At the very least, I would like that FOS1 continues to add support to newer PHP versions, and I'll try to help where I can. I'm in favor of progressively dropping support for the oldest PHP versions: keeping that support is only getting harder over time as newer versions of PHP come up, and, at some point, it may not even be possible to keep the support all the way back to PHP 5.x without having BC changes anyway. Personally, I'm only interested in 8.x+ these days, but I reckon that that is a big jump and wouldn't push for that right away; perhaps 7.x would be a good place to move to first.

As for bigger changes, nobody is starting a new project with symfony1... but, for those stuck with hard to rewrite projects built on symfony1, I think there can be room for some improvements a little beyond supporting newer PHP versions (and security updates). Here I don't mean building any new core features, but primarily modernizing the code and keeping up with the PHP ecosystem, for example, transitioning from Swiftmailer to symfony/mailer, updating the coding style, moving to PHPUnit tests, etc. — some of those are already under way and some may require minor BC breaks, but they can be documented on the UPGRADE file.

As for anything more ambitious, I don't know if there's a realistic path from symfony1 to anything on Symfony2+ end of things. As most of us are painfully aware, despite its name, Symfony2+ is a whole different thing, and it's a moving target, which doesn't help. Another challenge, I think, is that with symfony1 being quite a monolith, replacing parts of it will necessarily introduce some significant BC breaks before getting there... Hence, I'm not sure if a project:migrate-to-version-4 concept might be feasible, especially for large projects.

That said, if I were to dream high here (it's free, right?), I think one possible direction could be to make changes towards making the framework progressively less decoupled, for example, by implementing some of PHP PSR's, with the goal that at least some parts of the framework could be more easily replaced by, e.g., Symfony components (or anything else that follows the standard). In other words, I would like to see a path away from the symfony1 monolith, perhaps directionally towards being able to use Symfony components in it, but not necessarily to Symfony2+ (the framework). The main idea being to chip away at the monolith to make it smaller over time, and as more and more parts would be decoupled and/or replaceable, perhaps at some point the monolith could be small enough to realistically be replaced by something else by those of us currently stuck with large projects built on top of it.

alquerci · 2024-01-11T00:32:24Z

Good points @mentalstring

And now, the question of one billion.

To focus on what is used in practice.

How are yours projects attached to symfony1?

classes
methods
plugins
PHP version
ORM

make it smaller over time

connorhu · 2024-01-14T13:05:02Z

I would like to share some of my previous experiences and thoughts with you.

I used to do a project I started in symfony2 with 3 separate applications, never having actually worked with symfony1 and not knowing that there were multiple application architects by design. After a while I had to admit that it could be merged because symfony was actually going towards one application architecture. Because of this I think that symfony1 is actually multiple SymfonyCurrent Applications. Each Application in the app library can actually be interpreted as a separate Symfony.

Another SymfonyCurrent experience is that I started to port a custom php codebase, a rather poorly designed system, to symfony. The project owner requested that all changes should be small and that the result should be visible immediately (instant success experience, no giga changes to be lost). After three steps I had a fully functional integrated symfony:

I made the website routing use the symfony routing package (this actually seems unnecessary, but it was easier for me)
installed a complete symfony framework with all the necessary packages
made it forward my chosen route to symfony. then it boots HttpKernel and the rest is handled by symfony

There are parts that can't be converted to SymfonyCurrent with a command (View layer, sfConfig full static interface), but you can dump a lot of stuff from Symfony1 and convert it to SymfonyCurrent components. I also don't think you can get this migration down to the level of a single command.

Key moments:

we always know what type everything is (native php types, psalm/phpstan generics types), if not elsewhere but certainly in symfony1 code
the developer can always see what will expire/change: @Deprecation phpdoc, collecting and listing deprecation related errors
give developer a tool to handle changes (i converted symony1 to psr4 as a test. had to poke around a bit with the tool, but i finally did it. not a twig quality psr0=>psr4 conversion, but it shows that if you have the tool and everything has type you can achieve amazing things)
only php active support: https://www.php.net/supported-versions.php currently 8.2 and 8.3
should be a brach/version to keep the small bug fixes and old (>=7.x?) php support

What do I see when I look at the source code of symfony1?

cache => symfony/cache
command => symfony/console
debug => symfony/debug
event => symfony/event-dispatcher
mailer => symfony/mailer
i18n => symfony/translator
log => psr logger (monolog)
request, response => symfony/http-foundation
routing => symfony/routing
storage => symfony/http-foundation
lime => phpunit
yaml => symfony/yaml (with restrictions)
view => if I remember correctly symfony dropped the php based templating system, by default it only supports twig. but why shouldn't symfony1 get twig integration?
validator, form => ?
util/finder => symfony/finder
util/browser => symfony/browser-kit
util/domcssselector => symfony/css-selector
util/infector => symfony/string

Still, there is room for modernization here (even if not everything can be changed). Currently I see a distant goal of running a legacy symfony in a HttpKernel that Apps (backend, frontend etc) communicate with wrappers.

Along the wishes of @mentalstring we can start

By now, though, symfony has become very powerful in attributes. A completely parentless class can also be a controller, service and DI/autowire can handle it: https://symfony.com/doc/current/reference/attributes.html#dependency-injection

Branches:

1.5.x - >=php7.x support, nothing huge will change. small bugfixes, non-breaking change backports
1.[even].x - php8.3 and php8.2 support with "new" stuffs and deprecations (like symfony 7.[0..4])
1.[odd].x - identical with 1.[even].x minus the deprecated codes (like symfony 8.0)

What should I do next? I would make a 1.6.x branch and drop the <8.2 support. I would solve the 872 phpstan error (level 9) and make all classes have unit tests. Then I would look for a low level component and replace it with symfony/* coponent.

alquerci · 2024-01-15T20:25:19Z

That's very interesting.

But what will be the final state?

running a legacy symfony in a HttpKernel that Apps (backend, frontend etc) communicate with wrappers.

There are 2 distinct targets

1. SymfonyCurrent behind Symfony1

sf1 app is in front of SymfonyCurrent.
Where sf1 app boot and handle requests.

2. Symfony1 behind SymfonyCurrent

SymfonyCurrent is in front of sf1 app.
Where the HttpKernel boot and handle requests.

What target to choose?

My opinion is to choose the second one.

Having Symfony1 behind SymfonyCurrent.

The source code of symfony1 is dead, but the source code of the application running in production are alive.

I see the source code of live applications:

Example from test/functionnal/fixtures/ directory.

apps
├── frontend
│   ├── config
│   │   ├── dirmyconfig
│   │   ├── app.yml
│   │   ├── factories.yml
│   │   ├── routing.yml
│   │   └── frontendConfiguration.class.php
│   ├── lib 
│   ├── modules
│   │   ├── assetInclusion
│   │   │   ├── actions
│   │   │   │   └── actions.class.php
│   │   │   ├── config
│   │   │   │   └── view.yml
│   │   │   ├── data
│   │   │   └── templates
│   └── templates
└── backend
    ├── config
    ├── i18n
    ├── lib 
    ├── modules
    │   ├── someModule
    │   │   ├── actions
    │   │   ├── i18n
    │   │   ├── lib 
    │   │   └── templates
    │   └── sfI18NPlugin
    │       └── i18n                                                                                                                                                                          
    └── templates
config
├── dirmyconfig
├── databases.yml
├── filters.yml
├── properties.ini
└── ProjectConfiguration.class.php
lib
└── form
plugins
├── sfAutoloadPlugin
├── sfConfigPlugin
└── sfI18NPlugin

What is the smallest thing to do, to validate or invalidate that the goal is reachable?

The HttpKernel is huge, but it can be simplified at the minimum.
- Does a partial support is usable? I do not think do.
The Console component is smaller than HttpKernel.

There are 2 distinct endpoints to tackle.

What can we do in 6 months, duration of SymfonyCurreny version?

alquerci · 2024-02-11T15:41:42Z

Ho, a wrapper of sf1 into Symfony2 until 4 already exists.

https://blog.theodo.com/2015/01/wrap-up-your-legacy-application-with-symfony/

The bundle: https://github.com/theodo/TheodoEvolutionLegacyWrapperBundle/tree/master

alquerci mentioned this issue Feb 27, 2019

Remove create_function call as it is deprecated in 7.3 FriendsOfSymfony1/doctrine1#65

Merged

alquerci mentioned this issue Nov 18, 2023

Add support for SameSite session cookies #215

Open

alquerci mentioned this issue Feb 9, 2024

drop php <8.2 version support #314

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

FriendsOfSymfony1 organization what next? #201

FriendsOfSymfony1 organization what next? #201

alquerci commented Nov 9, 2018 •

edited

Loading

e1himself commented Aug 27, 2019 •

edited

Loading

alquerci commented Aug 27, 2019

alquerci commented Aug 27, 2019 •

edited

Loading

e1himself commented Aug 28, 2019 •

edited

Loading

alquerci commented Aug 31, 2019

e1himself commented Sep 2, 2019

alquerci commented Sep 3, 2019 •

edited

Loading

thirsch commented Mar 23, 2021

alquerci commented Mar 25, 2021

connorhu commented Jan 8, 2024 •

edited

Loading

ingcarlosperez commented Jan 8, 2024

alquerci commented Jan 8, 2024

sbrowett commented Jan 8, 2024 via email

e1himself commented Jan 9, 2024 •

edited

Loading

alquerci commented Jan 9, 2024

e1himself commented Jan 9, 2024 •

edited

Loading

e1himself commented Jan 9, 2024 •

edited

Loading

mentalstring commented Jan 10, 2024 •

edited

Loading

alquerci commented Jan 11, 2024 •

edited

Loading

connorhu commented Jan 14, 2024 •

edited

Loading

alquerci commented Jan 15, 2024

alquerci commented Feb 11, 2024

FriendsOfSymfony1 organization what next? #201

FriendsOfSymfony1 organization what next? #201

Comments

alquerci commented Nov 9, 2018 • edited Loading

Questions

I suggest this to-do list.

I suggest its rules

Summary of comments

The mission of FriendsOfSymfony1 organization

Goals

e1himself commented Aug 27, 2019 • edited Loading

alquerci commented Aug 27, 2019

alquerci commented Aug 27, 2019 • edited Loading

e1himself commented Aug 28, 2019 • edited Loading

alquerci commented Aug 31, 2019

e1himself commented Sep 2, 2019

alquerci commented Sep 3, 2019 • edited Loading

thirsch commented Mar 23, 2021

alquerci commented Mar 25, 2021

connorhu commented Jan 8, 2024 • edited Loading

ingcarlosperez commented Jan 8, 2024

alquerci commented Jan 8, 2024

sbrowett commented Jan 8, 2024 via email

e1himself commented Jan 9, 2024 • edited Loading

alquerci commented Jan 9, 2024

e1himself commented Jan 9, 2024 • edited Loading

e1himself commented Jan 9, 2024 • edited Loading

mentalstring commented Jan 10, 2024 • edited Loading

alquerci commented Jan 11, 2024 • edited Loading

connorhu commented Jan 14, 2024 • edited Loading

alquerci commented Jan 15, 2024

There are 2 distinct targets

1. SymfonyCurrent behind Symfony1

2. Symfony1 behind SymfonyCurrent

What target to choose?

What is the smallest thing to do, to validate or invalidate that the goal is reachable?

What can we do in 6 months, duration of SymfonyCurreny version?

alquerci commented Feb 11, 2024

alquerci commented Nov 9, 2018 •

edited

Loading

e1himself commented Aug 27, 2019 •

edited

Loading

alquerci commented Aug 27, 2019 •

edited

Loading

e1himself commented Aug 28, 2019 •

edited

Loading

alquerci commented Sep 3, 2019 •

edited

Loading

connorhu commented Jan 8, 2024 •

edited

Loading

e1himself commented Jan 9, 2024 •

edited

Loading

e1himself commented Jan 9, 2024 •

edited

Loading

e1himself commented Jan 9, 2024 •

edited

Loading

mentalstring commented Jan 10, 2024 •

edited

Loading

alquerci commented Jan 11, 2024 •

edited

Loading

connorhu commented Jan 14, 2024 •

edited

Loading