New maintainers needed. Keep Silex alive.

[GBeushausen]

Hi,

this is so sad to see that development for Silex is being stopped. To me Silex was the best MicroFramework for PHP. I have dozens of projects depending on it. I think the current maintainers had done a great job.

The problem ist, not all my customers will be willing to pay for migrating to Symfony. Also in the past years i've made this experience way too much, that you write an application and then all off a sudden the Framework is being abandoned or the next version is incompatible with your old code. For example Zend Framework 1. For this reason, i will never use a full fledged framework again. MicroFrameworks are at least so small, that you can support it your self if you must.

I don't want to see Silex to dissappear. It was way to good. I would like to ask if there would be anybody willing to help me with a fork and help Silex to stay alive, even if it has to be renamed. The main goal would be to establish a stable release, that will be supported for at least 3 years. The second goal would be to catch up with Symfony and be able to use Symfony 4 components.

Best,

Gunnar

[stof]

Well, the thing is, if you use Symfony 4 components, you can get a similar development experience (and better performance thanks to the cached compiled container) when using the Symfony DI component and Flex than when using Silex.

The thing is, Symfony 4 does not require you to use the full-fledged framework.

[fabpot]

Just to be clear, Silex is not abandoned. We think that migrating to Symfony 4 is the best option for current Silex users.

There is no need to fork Silex. If a group of people is interested in maintaining Silex, I would be more than happy to give the keys. I've tried in the past, and it didn't work. So, let's see if some other developers want to join you.

Also see my comment here: http://symfony.com/blog/the-end-of-silex#comment-22093

Anyway, thanks for supporting Silex.

[devsdmf]

I have the same feels as @GBeushausen, I have a lot of projects written using Silex and I do not want to migrate for Sf4 this projects (not now), so I'm open to help maintain silex alive.

[GBeushausen]

Thanks @fabpot and thanks @devsdmf for joining me . That would be wonderful, if we where able to continue with Silex. I would commit to spend some serious time on this project and try to get support from others as well.

[hkdobrev]

I understand the maintainers viewpoint, but I think making it compliant with Symfony 3.4 would be a better point to deprecate it while leaving the LTS version of the latest Symfony 3.

[devsdmf]

I guess that update the silex's dependencies to Symfony 3.4 components, and bump the version of silex to 3.0, would be a great step (:

[GBeushausen]

@stof I've played a bit with Symfony 4 & Flex. It does seem to require a specific file layout. I've got applications with dozens of modules and bundles. This seems to be a very high cost to migrate to that particular structure and i don't see any sense in doing so. The good thing about microframeworks is that they don't force any constraints on you. With normal frameworks like Symfony 4 i have to abide to the rules the inventors of that framework designed. This was designed for a specific purpose but it's not given, that any particular application fits in that purpose the designers of the framework had in mind.

Also it seems that using yaml config files is a must, wich i'm not sure about. But i don't want to use that. So please forgive me, i love the components, but i hate the framework.

@fabpot How can we proceed to keep Silex alive? Can we at least remove the maintenance warnings for now, so we don't scare any possible new users away? Thanks.

[fabpot]

@GBeushausen Keeping Silex alive is simple: the new group of developers willing to help need to start contributing, fixing bugs, adding support for new versions of Symfony, adding new components support, answering issues, asking to close old issues, ... Whenever someone or a group of people contributes to a level that proves their commitments, I will happily give them access to the repo. I won't remove the warning until then for one reason: I know for a fact that good intentions are not enough. Maintaining a project is a lot of work. It means commitment. And from my past experience, most people won"t help in the long term. I don't want to give the impression that Silex is maintained again if that's not really the case. That would do more harm than good. What we can do is tweaking the warning to point to this issue, asking for help. I would accept a PR that would do that as a first step.

[GBeushausen]

@fabpot I know where you're coming from and can fully agree with your intentions. I'll start working on the things you've metioned. But comming from a commercial background i need to acquaint myself a bit to how things work in Github. Anyway thanks for the opportunity.

[devsdmf]

So let's do this!

[flip111]

Maybe rename the topic title now that a fork doesn't seem to be needed

[mTorres]

@stof I've played a bit with Symfony 4 & Flex. It does seem to require a specific file layout. I've got applications with dozens of modules and bundles. This seems to be a very high cost to migrate to that particular structure and i don't see any sense in doing so. The good thing about microframeworks is that they don't force any constraints on you. With normal frameworks like Symfony 4 i have to abide to the rules the inventors of that framework designed. This was designed for a specific purpose but it's not given, that any particular application fits in that purpose the designers of the framework had in mind.

Also it seems that using yaml config files is a must, wich i'm not sure about. But i don't want to use that. So please forgive me, i love the components, but i hate the framework.

@GBeushausen you didn't really grasp the flexibility of SF4. You can use any language format and you can change the directory structure if you want.

Sorry for the OT, but those comments seemed unfair

[fabpot]

So, I'm spending some time on Silex to fix the major "blockers" for an easier transition to a new core team. I've closed a bunch of old issues, merged "simple" pull requests, fixed tests, fixed support for Symfony 3.4, added support for Symfony 4.0. More to come.

[fabpot]

I'm done for today. v2.2.3 is out and #1607 removes obsolete code for 2.3.0.

[GBeushausen]

Thanks. We really apperciate this.

[phith0n]

In my mind, micro framework means "I can put all the code in a file, and everything works well", so I think Silex is the best micro framework. Maybe I am not proficiency in Symfony 4, but I think it is not a "micro framework". So please keep Silex alive.

[jibundeyare]

@GBeushausen Hi. I don't have much time available, but I could spend some sorting issues or writing docs.

Personnaly I use Silex as a teaching tool. It's a nice bridge between raw PHP and the magic of Symfony. So I'd rather see it alive for a few years more.

[flip111]

I can put all the code in a file, and everything works well

I was curious if symfony 4 code place all the code in a single file. I didn't get around to that .. but i followed the "create your own framework" with symfony components to see what is the minimal you have to do. Maybe it's a good starting point for making symfony in such a way that all framework code can be in a single file. repo is here https://github.com/flip111/Simplex

[GBeushausen]

@jibundeyare Thanks. It's great to have you onboard

[GBeushausen]

@phith0n That might be one use case for a micro framework. It's also often used as a thin layer on which one builds it's own framework for their specific business use case.

Silex is also great for migrating old legacy code. Just put it in front of an old app and let it handle the new routines, while you can configure it so that unmatched routes are handled by the legacy code.

[agilare]

Silex is also great for migrating old legacy code. Just put it in front of an old app and let it handle the new routines, while you can configure it so that unmatched routes are handled by the legacy code.

I agree 110%, it was the perfect choice for me to migrate a big legacy app in the view of using Symfony later.

[fabpot]

@GBeushausen @agilare I would argue that doing the same with Symfony is even better. I don't see th benefit of using Silex to migrate to Symfony from a legacy application. There is plenty of talks that describe how to do it and that's easy and fast. No need to use Silex here.

[fabpot]

I'm going to close this issue now as there is no need for people to argue whether Silex is great or not. We all love Silex, including me. Everything has been said now. If people want Silex to continue, we need people taking over. So, see you all on your next pull request :)

[danitome24]

I'll be interested to help on mantaining silex!

[hidix]

Sorry to see Silex project delete or not anymore developped. It was very useful for small organisations as associations. I try to continue the dev on php 7.2 and symfony 3.4.8. The main problem seem to be in the AdminController and also in the use of salt instead of password hash. It could be relevant to work on it. I used silex 2.2.4 and all reposetories have been updated. I will try to do something about it. Best regards. hidix

[InfopactMLoos]

At my company we just updated all Symfony components to LTS version, latest LTS 3.4 has support till 2021 so that should give some time. Of course there still is some Silex code left that will not be maintained by Sensiolabs anymore but if the community pitches in that codebase should be easy to maintain. I don't think we need any new features just bug and security issue fixes.

[patrick-fls]

@InfopactMLoos I couldn't agree more. Us too we're a small company and we moved all components to 3.4 and php 7.2. We will definitely support the next LTS component version for our own usage - Silex isn't going anywhere in our company. While I can't make the promise that we can keep maintaining every aspects of Silex, we'll definitely pitch in when the time comes.