Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
I bet this won't sound surprising to many long-time users of this library at this point but the time to call for help from the community has finally come, albeit a bit late I guess.
Just a few words on why we've reached this point. Predis has always been mostly a one-man project aside from a few good PRs and various kinds of contributions for which I'm still thankful after years. This didn't pose much issues at least until I started having less and less free time to dedicate to my opensource activity which basically amounted to zero in the last 18 months. Truth to be told part of the problem is also that I don't have the same motivation I had a few years ago to maintain such a library, but I hated to admit it. That said, if there's one thing that fueled my reluctance to call for help is that I've always been quite meticulous with my work (which doesn't mean being perfect, whatever that means) but many PRs I received in the past were admittedly sloppy, with no care for the coding style adopted by the project, glaring errors, conflicts with the overall design of the library or missing tests just to name the most striking examples of what I mean.
So what now? Basically I'm looking for contributors that are seriously interested to help with maintaining Predis and that are willing to strive for the same meticulous approach. I don't expect people rushing here to take up on such task, the fact that Predis is a pure-PHP implementation of the Redis protocol surely attracted critics and in the meanwhile PhpRedis matured so much in terms of features and stability so there's probably less need for it, but I don't want to reach the point of having to mark this project as abandoned because I think it still has its own place in the PHP + Redis ecosystem. Obviously I'll try to help as much as possible especially when there are doubts about Predis internals and the overall design of the library, just don't take readiness for granted due to limited time.
The most urgent task is to rank open issues and fix them to push a new relase in the v1.1 branch, some open PRs address a few of these issues but they probably need some work. At first, contributors willing to help should work on their own forks to polish the code before submitting proper PRs for fixes, but if any currently open PR indeed doesn't need anything more than a merge because it passess the test suite and doesn't break anything else then let me know and I'll merge it ASAP. I may consider giving access to the main repository to contributors that earned my trust, I guess you undestand that I cannot do such a thing immediatly.
The master branch is meant to become v2.0, but since it diverged quite a lot from v1.1 most fixes cannot be easily merged. At first I intended to maintain both v1.1 and master-to-be-v2.0 but in retrospect I guess that plan actually backfired so now the plan is to just fix v1.1 for both implementation bugs and compatiblity issues with newer PHP versions, maybe a few new Redis commands, and leave it at that. On the master branch, aside from applying the same fixes, we should drop support once and for all for PEAR and older PHP versions and rework parts of code that could benefit from new features introduced in PHP 7 before implementing anything new.
I'm not sure how it will go, but let's discuss how to make it work. I'd really prefer to discuss this publicly but if you need to contact me privately then go ahead.
Daniele, thank you for sharing your thoughts and be open for contributions; as I mentioned I would like to contribute to bringing back predis back alive, I'm a heavily Redis user and yes PhpRedis would make sense most of the time, but predis allows the no Extension dependency to move ahead with the code in many ways local, serverless, containers; hence my desire to see it moving forward.