Friends of Symfony1 (FOS1) Organization?

[thePanz]

From the idea on #100 .. what do you think about merging our efforts to have a FriendsOfSymfony1 (FOS1) organization where let all the Symfony1 related works be unified?

Meaning also to have two different branches of Symfony 1.5.x (with BC-breaks) and Symfony 1.4.x (with fixes and backports only) I saw that other users proposed (and worked) on such 1.4.x updating without BC breaks here: https://github.com/punkave/symfony1 by @boutell

[boutell]

I'm all for it as long as it's well maintained — there need to be enough
people who have commit privileges for the 1.4 branch that it doesn't go
stale, yet everyone doing so needs to firmly understand that there are
zero bc breaks there.

On Fri, Aug 14, 2015 at 5:48 AM, Ema Panz [email protected] wrote:

From the idea on #100 #100
.. what do you think about merging our efforts to have a FriendsOfSymfony1
(FOS1) organization where let all the Symfony1 related works be unified?

Meaning also to have two different branches of Symfony 1.5.x (with
BC-breaks) and Symfony 1.4.x (with fixes and backports only) I saw that
other users proposed (and worked) on such 1.4.x updating without BC breaks
here: https://github.com/punkave/symfony1 by @boutell
https://github.com/boutell

—
Reply to this email directly or view it on GitHub
#102.

*THOMAS BOUTELL, *DEV & OPS
P'UNK AVENUE | (215) 755-1330 | punkave.com

[thePanz]

Waiting for @j0k3r and @GromNaN feedback too.
Regarding the BC breaks: unit-tests (plus Travis integration?) could be used to ensure that the 1.4 branch do not get BC breaks. As far as I know the 1.5 branch is not fully successful with all the symfony1 tests.

[thePanz]

Dear @boutell, given the silence of @j0k3r and @GromNaN (or are they on holidays? :) ) I will create a FriendsOfSymfony1 (FOS1) organization, where I will start pushing my three SF1 plugins (listed here: #100 (comment)). From my preliminary tests they are compatible to sf 1.4 (no code changes at all) and I was able to substitute the previously downloaded plugins just using composer. Not big plugins, but just a start. I'd like to semantically version the plugins, namely 1.4.* versions MUST be BC with sf 1.4.. but that need to be agreed at organization level.
In this direction I'd like to see also the sfDoctrineGuardPlugin to be moved in the FOS1 organization.

The reason why I am pushing to an Organization is to avoid a growing number of forks of Symfony1 (145 at time of writing) with good contributions spread across multiple repositories: as and example the Virtuvia fork https://github.com/Virtuvia/symfony1 maintained by @isleshocky77 and @mlehner .

Regarding moving sf 1.4 under FOS1 organization: I'd like to have a composer-enabled version before pushing your repository there, ensuring that Doctrine1 will be composer-enabled is a must here.
I'd like to have a clear and easy "upgrade to SF1 + composer" path, where the only needed edits will be related to the ProjectConfiguration.class.php file to point to the correct sfCoreAutoload.class.php. I guess that the vendor/autoload.php provided by composer could be used to avoid to specify paths under vendor.

Any further thoughts? :) Cheers

[isleshocky77]

@thePanz I like this idea a lot even though we're in the active process of trying to transition little by little to Symfony2. However, i think I would like to see us move on to a 1.5 version for the support of composer and the other changes we started putting in and fixing.

Thoughts?

Edit: This has a lot to do with I think it's a terrible idea for us to continue on with 1.4.20+ when there is obvious change in functionality, and I really hate what I've been doing with 1.4.20.XX as a stop-gap for our purposes.

[boutell]

From our standpoint @punkave, the only branch we're interested in is the
most boring 1.4 compatible one possible without security flaws (:

On Wed, Aug 19, 2015 at 11:14 AM, Stephen Ostrow [email protected]
wrote:

@thePanz https://github.com/thePanz I like this idea a lot even though
we're in the active process of trying to transition little by little to
Symfony2. However, i think I would like to see us move on to a 1.5 version
for the support of composer and the other changes we started putting in and
fixing.

Thoughts?

—
Reply to this email directly or view it on GitHub
#102 (comment).

*THOMAS BOUTELL, *DEV & OPS
P'UNK AVENUE | (215) 755-1330 | punkave.com

[thePanz]

@isleshocky77 thank you for your reply! With "transition to Sf2" do you mean that you're integrating sf1 with sf2 components? i have done it by requiring two different autoloaders (sfAutoload and composer's one), but I consider it an hackish approach :)
I will create the FOS1 organization soon, but I'd like to know if your current sf1.4.20.x version is still back-compatible with sf1.4?

[thePanz]

Sounds great! Let's create FOS1 and discuss it there :) Nice to have you on board! :)

[isleshocky77]

@boutell Sorry, you'll have to remind me. Symfony1 was before semantic numbering, right? So 1.3 to 1.4 had b.c breaks? 1.4.1 to 1.4.2 were not just security fixes? I think they also included bug fixes and some b.c features?

@thePanz I believe our branch should still be b.c. A lot of the changes we did were for composer, code clean-up, and some bug fixes. I suppose we could look into making sure all the tests are still in the same status.

I think we may also have some bug fixes for doctrine in there as well although I would prefer seeing us break that out properly.

[boutell]

Yes, the 1.4.x series did contain some bug fixes that were "bc breaks" if
you'd already worked around the bug at project level. At the stage of
maturity our 1.4.x projects are at right now, though, we wouldn't want even
that much. Keeping those suckers running is all about using CentOS 7 (for
PHP 5.4.x security fixes through 2024) and migrating clients to nodejs at
every opportunity (:

On Wed, Aug 19, 2015 at 11:33 AM, Stephen Ostrow [email protected]
wrote:

@boutell https://github.com/boutell Sorry, you'll have to remind me.
Symfony1 was before semantic numbering, right? So 1.3 to 1.4 had b.c
breaks? 1.4.1 to 1.4.2 were not just security fixes? I think they also
included bug fixes and some b.c features?

@thePanz https://github.com/thePanz I believe our branch should still
be b.c. A lot of the changes we did were for composer, code clean-up, and
some bug fixes. I suppose we could look into making sure all the tests are
still in the same status.

I think we may also have some bug fixes for doctrine in there as well
although I would prefer seeing us break that out properly.

—
Reply to this email directly or view it on GitHub
#102 (comment).

*THOMAS BOUTELL, *DEV & OPS
P'UNK AVENUE | (215) 755-1330 | punkave.com

[isleshocky77]

@boutell I see. I'm not 100% sure; however, we would have to look through our commits to make sure they're still compat with PHP 5.4.x as we're now running past that and have updated a lot of our code-styles for things that may have not been supported in PHP 5.4.

I'm not sure if any of that is in the Symfony changes though.

it appears the travis-ci is setup to run the test suite with the different versions of php so we could actually see where we stand fairly quickly once a FOS1 is setup.

[isleshocky77]

Just a thought, but why create a FOS1/symfony1 rather than seeing if we can get a maintainer(s) of symfony/symfony1?

I can see making a FOS1 for all of the plugins to be ported over and maintained (including possibly sfDoctrinePlugin); however, it seems silly to have FOS1/symfony1 when we could just concentrate on symfony/symfony1.

From the few Symfony conferences and meetups I've been to (as well as the github network graph) there is obviously still a large community of people maintaining and iterating on symfony1 projects.

CC: @fabpot

[j0k3r]

I'm not really for this idea to create a FOS1 organization. I think it will send the wrong message to the community: you are safe, we are going to maintain some sf1 plugins and you'll be able to continue working on sf1.

This is definitely not the right way to guide people to jump on Sf2.

When we started this fork, it was mostly because our whole stack was built on sf1 and we needed new things to go further (composer integration, DIC, PHP 5.5+ support, etc ...). Since then, we have started a migration to Sf2 (ie: we do not include sf1 inside Sf2, we rewrite stuff). And all new stuff are now done on Sf2.

At this point, our fork feet our needs. Not everyone is happy with BC breaks we introduced and that's why @boutell created a new fork and cherry-picked some of our commits. And it's great, this is the way open source works.

So if this organization is created I think it might still be great to have a centralized fork of sf1 (without BC, so everyone is happy :))

[boutell]

That's a pretty good summary. I think there are at least two truly distinct
sets of goals here, one group that wants strict bc and nothing but security
/ newer PHP version fixes (and the latter only when it breaks nothing),
because they are already 80% gone from SF1 in their projects... and another
group that is willing to make changes, however minor, to keep their old
projects running with a new branch. I totally understand both perspectives
but they aren't the same.

On Wed, Aug 19, 2015 at 3:25 PM, Jeremy Benoist [email protected]
wrote:

I'm not really for this idea to create a FOS1 organization. I think it
will send the wrong message to the community: you are safe, we are
going to maintain some sf1 plugins and you'll be able to continue working
on sf1.

This is definitely not the right way to guide people to jump on Sf2.

When we started this fork, it was mostly because our whole stack was built
on sf1 and we needed new things to go further (composer integration, DIC,
PHP 5.5+ support, etc ...). Since then, we have started a migration to Sf2
(ie: we do not include sf1 inside Sf2, we rewrite stuff). And all new stuff
are now done on Sf2.

At this point, our fork feet our needs. Not everyone is happy with BC
breaks we introduced and that's why @boutell https://github.com/boutell
created a new fork and cherry-picked some of our commits. And it's great,
this is the way open source works.

So if this organization is created I think it might still be great to have
a centralized fork of sf1 (without BC, so everyone is happy :))

—
Reply to this email directly or view it on GitHub
#102 (comment).

*THOMAS BOUTELL, *DEV & OPS
P'UNK AVENUE | (215) 755-1330 | punkave.com

[isleshocky77]

I'm in the camp that the only reason these things are being maintained is during transition to SF2. For that reason a lot of the changes are for keeping up with PHP 5.5+, composer, and DIC which I think will have some b.c breaks for people not doing this. This is why I proposed that most of that should probably go into a 1.5 branch. @boutell In my opinion it's the people who are moving off the project that really should have been on a 1.5 branch while doing it.

[boutell]

Sure. We started our move a few years ago though and haven't done a new
Symfony 1.4 project in years. For us it just makes no sense to change those
projects at all unless they are demonstrably broken or insecure. CentOS/Red
Hat takes care of making sure PHP 5.4 is secure until we're (finally) done
with it (:

On Wed, Aug 19, 2015 at 4:06 PM, Stephen Ostrow [email protected]
wrote:

I'm in the camp that the only reason these things are being maintained is
during transition to SF2. For that reason a lot of the changes are for
keeping up with PHP 5.5+, composer, and DIC which I think will have some
b.c breaks for people not doing this. This is why I proposed that most of
that should probably go into a 1.5 branch. @boutell
https://github.com/boutell In my opinion it's the people who are moving
off the project that really should have been on a 1.5 branch while doing it.

—
Reply to this email directly or view it on GitHub
#102 (comment).

*THOMAS BOUTELL, *DEV & OPS
P'UNK AVENUE | (215) 755-1330 | punkave.com

[fabpot]

Interesting discussion here. If there is a group of people motivated and committed to update symfony1 to make it compatible with newer versions of PHP, and to fix bugs, I would be more than happy to support them.

[thePanz]

Nice to have Fabien here! :)
Regarding Symfony1: we must be very clear on the main goals of the new branches, plus we must clearly state that Symfony1 must not be used for new web projects (as already reported on Symfony1 official page). Branch 1.4.x will receive bug-fixes and feature backport only, with no BC breaks.
Unfortunately I still don't know how we can add Composer to SF1.4, without BC breaks. Any thoughts?

I'm going to move the three SF1 plugins I created under the FOS1 organization soon, adding them to Packagist as well.

[boutell]

For the 1.4 branch I would suggest not adding composer at all, but I
recognize I'm probably an unpopular minority there.

On Thu, Aug 20, 2015 at 4:56 PM, Ema Panz [email protected] wrote:

Nice to have Fabien here! :)
Regarding Symfony1: we must be very clear on the main goals of the new
branches, plus we must clearly state that Symfony1 must not be used for new
web projects (as already reported on Symfony1 official page). Branch 1.4.x
will receive bug-fixes and feature backport only, with no BC breaks.
Unfortunately I still don't know how we can add Composer to SF1.4, with BC
breaks. Any thoughts?

I'm going to move the three SF1 plugins I created under the FOS1
organization soon, adding them to Packagist as well.

—
Reply to this email directly or view it on GitHub
#102 (comment).

*THOMAS BOUTELL, *DEV & OPS
P'UNK AVENUE | (215) 755-1330 | punkave.com

[davidvegacl]

Hi! I really want to keep Symfony1 alive, not only because old projects running on it, but because some current projects we built too fast with well-working-and-tested plugins with my team. I know that I'm on the minority and as said by @boutell, unpopular, but SF1 still works very well to mid-size projects and I consider it secure an reliable, and step up to SF2 is matter of time.

It's nice to read Fabien supporting this idea.

Go ahead with FOS1, I will stay tunned :D

Greetings from Chile!

(Sorry about my poor english)

[boutell]

Oh, I wasn't saying you're the unpopular one David (: My stance of
"absolutely nothing but security fixes and showstoppers" is probably the
unpopular one.

On Thu, Aug 20, 2015 at 5:40 PM, David Vega Regollo <
[email protected]> wrote:

Hi! I really want to keep Symfony1 alive, not only because old projects
running on it, but because some current projects we built too fast with
well-working-and-tested plugins with my team. I know that I'm on the
minority and as said by @boutell https://github.com/boutell, unpopular,
but SF1 still works very well to mid-size projects and I consider it secure
an reliable, and step up to SF2 is matter of time.

It's nice to read Fabien supporting this idea.

Go ahead withs FOS1, I will stay tunned :D

Greetings from Chile!

(Sorry about my poor english)

—
Reply to this email directly or view it on GitHub
#102 (comment).

*THOMAS BOUTELL, *DEV & OPS
P'UNK AVENUE | (215) 755-1330 | punkave.com

[thePanz]

Nice to have you on board @VegaDavid!

The FOS1 Organization can be found here:
https://github.com/FriendsOfSymfony1

With the first three plugins published, go on and add yours! Please tag and ensure to use a semantic versioning structure to further define which version is BC with latest Symfony 1.4.20

@boutell : I agree about a branch with your requirements, and everything that is not "absolutely nothing but security fixes and showstoppers" should go to the next v1.5.x release branch

[davidvegacl]

Ok @thePanz!

Can you please explain me how to tag an branch my plugins with te FOS1 standard? :D

Anyway, here is my team's github with some plugins that we use on our projects: https://github.com/izarus If any of them may be useful for others I can write some docs and push them to FOS1.

[fabpot]

IMO, adding Composer to symfony1 does not make sense if people are NOT using symfony1 for new projects. But there is one more piece to take care of, and that's plugin installation. We might want to open-source this part of the infrastructure and host it on a "public" server if people want to keep that running "forever".

[GromNaN]

Is there anybody interested in supporting this fork ?
@j0k3r & I are no longer involved in legacy symfony1 projects.

[fabpot]

One issue though is that you cannot install plugins anymore as the symfony1 infrastructure was shutdown a few months ago.

[thePanz]

@GromNaN I still have a legacy Symfony1 project, which I migrated to your 1.5.x version. But I am getting more and more reluctant to work on that project (don't tell it to my old client :) ). Unfortunately I'd like to focus more on SF 4.x projects.

Regarding SF1 plugins: I created long ago a GitHub organization where I uploaded some of the plugins I used/updated https://github.com/FriendsOfSymfony1. They can be installed/used on top of SF 1.5.x with composer.

On the doctrine1 side: Lexpress maintained the code, while I noticed a lot of recent activities from @endelwar ... should we ask them to join the "maintenance" team?

[boutell]

We maintain a fork here, bare minimum changes only to work on versions of PHP we need and not be insecure:

https://github.com/punkave/symfony1

But we haven't really solved the plugins problem; lately we just check them all directly into our projects based on the last copy we've got, while we explain to the client that no, really, we can't support this forever (:

[boutell]

Of course we're grateful that Symfony 1 produced websites clients don't want to let go of (:

[e1himself]

We're still using symfony1 on our evolving long living project. As lexpress/symfony1 philosophy was a near-end-of-life support for stale old symfony1 projects, we've forked the fork :D We need a way forward without rewriting everything to the next-modern-framework.

In case anyone's in the same position as we are, here it is: https://github.com/rock-symphony/rock-symphony

[alquerci]

@fabpot The usage of composer is the only open-source alternative as composer/installers package supports symfony1-plugin type for plugins installation. The plugin directory will be another vendor like directory.

Pragmatically generate:project and generate:app tasks can be removed as existing project should never use it.

Moreover we can use abandoned composer configuration to discourage people to use it for new projects and set symfony/skeleton as recommended alternative.

Everyone wants to migrate all its projects to Symfony4+ so the goal of the repository will be:

• No BC breaks to follow semver
• security fixes
• bug fixes
• The main enhancement is to facilitate the migration to Symfony4+ - use Symfony DIC

Now we need to move this repository to people able to maintain it where we move forward toghether. The GitHub organization FriendsOfSymfony1 is a solution where we can manage symfony1 and its plugins but also repository like as doctrine1.

The quality policy of the project need for sure be closed as much as possible to the latest version of Symfony to not decrease the code coverage with pertinents test cases.

Personally I can only be an active contributor for now as I am working on a project using it on production with WEB and API use cases.

cc @GromNaN @thePanz

[mkopinsky]

We are still using symfony1, and are grateful to the lexpress folks for this fork. For the moment we're on our own fork which diverged due to one PR which the lexpress folks (understandably) didn't want to merge since it introduced breaking changes to a class. This is the first I've heard of @e1himself 's rock-symphony fork, and I will take a look at it.

We are installing plugins through composer, and it is working great for us. (We did have an oh shit moment when the symfony svn server shut down, and we had to push our local copy to our own svn server. We have since moved everything to git.)

I do think there is value in centralizing whatever maintenance is going on for symfony1 rather than having multiple forks of forks. Whether that repo belongs in lexpress, friendsofsymfony1, or elsewhere is immaterial. I would be happy to take on some responsibility for maintenance, or coordination thereof.

For websites, dropping support after a time is feasible; what I work on is a large, complex application built on symfony1. We've introduced some Laravel/Illuminate components lately (for queues, caching, etc.) but our models and controllers are still symfony1 and doctrine1. Since there isn't really a clear migration path to sf2+ dropping support or rewriting hasn't really been an option.

I would love if one thing that comes out of this collaborative is a set of docs on how to migrate a symfony1 project to sf2+ (or whatever else). Can we convert a plugin into a bundle? If so, what parts of that are copy/paste vs total rewrites? Is it possible to use Doctrine1 with sf2+ as an intermediate step before we migrate our models into a newer ORM? I'm sure there are others in the community (or even in this thread) who've dealt with some of these questions, and I'd love to hear (and document) their experiences.

[GromNaN]

The repository has been moved to FriendsOfSymfony1/symfony1, same with FriendsOfSymfony1/doctrine1.

[mkopinsky]

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.

[alquerci]

@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?