Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Some questions about the future of the Doctrine Project #6211
This morning, in the Symfony Slack chat, I posted the following message:
I won't copy the entire discussion because there were a lot of messages, but at the end someone suggested to ask you directly about the future of the Doctrine Project. So here are some questions:
Thanks for your time!
We're planning to release 2.6 and call it the last 2.x version, freezing any request for improvements.
No roadmap: the roadmap is "we do what we can, when we can", sorry.
Most public API will stay as-is until we got to a decent cleanup state and can take decisions about the future of the interfaces.
No - at this rate it will be likely no earlier than 2018, unless we just do a release due to a forced BC break/security issue leading to BC break.
I think the amount of prototyping work done by @guilhermeblanco doesn't play well with coordination work. Yes, he is going "cowboy-coder" here, but I really do trust him on most design decisions behind the scenes, as he's been very meticulous and informed with his work.
We also don't have the time to coordinate work, and the domain knowledge behind the ORM internals is huge and sadly only written down in the Java world.
We had more than 1000 open issues for ages - the fact that we moved them to Github a bit over a year ago simply exposes the number to the "general public". There are no critical issues or known vulnerabilities at the moment, so there may be a big purge after the API changes (3.x).
We could need somebody to go into open PRs and find good reasoning for rejecting them. Yes: I do intend reject there, as most issues on the ORM starting from version 2.4.0 are edge-case scenarios, mapping weirdness, exotic relational databases and structures.
The ORM is an extremely stable tool, so I wouldn't worry too much about the amount of issues, rather than the quality/relevance. Also, we are extremely alert on security issues, which we also didn't have in a while.
If somebody wants issue rights and go in and do a close-spree (with careful explanations and cross-referencing), then I'd gladly grant those.
Other than that, I can suggest sponsoring (actual
I'll answer the questions from my own POV. I think it's ok if we answer individually on our own perspective and then take this discussion offline and come up with a project response.
We have enough fixes/features on
I'm focused on working purely on 3.0. However, I couldn't touch it since October due to a variety of personal reasons (I switched jobs, onboarded a huge project on initial phase which required some extra dedication and now took a month of well deserved vacation) and will resume my development once I get back home.
We share a Google Doc describing our wish list and that is what we're doing on ORM.NEXT Project. Not everything is listed there, since as we evolve, we might change plans. There're thousands of lines of code to be written and thousands to be dropped.
As it currently stands,
I have yet to review 3.0 issues and close/answer them properly and annotate with similar elements on ORM.NEXT project. Should do that any day tbh.
No, but I was committed to dedicate 2-3h daily on this project to work on 3.0.
There're a couple blocking changes required before we unleash the ability to split work with others.
The change to ClassMetadata will unleash changes to be made everywhere. One good example is the ability to compile metadata PHP classes that can take advantage of opcache and remove the need for metadata cache forever. As I work on OOing Metadata, I'm also ensuring that Export to PHP is adequate, so consuming it later would be a joy.
Most of the issues are actually user issues, not bugs on ORM. As we evolve, we add new ways of implementing similar features, which lead people to use them in funky ways.
as I already mentioned in the Slack discussion, I try to comment on some issues in order to help, but my time is quite limited right ATM.
This was referenced
Jan 3, 2017
Looks like it's well deserved some updates around this.
I've been dedicating 15-20h/weekly on
Right now I'm in the process of re-building the ClassMetadataFactory and also the way we load, cache and build ClassMetadata instances. It's expected that we have a significant performance improvement over this, since we'll no longer have to validate and complete arrays. It'll also be opcached.
As soon as this work is finalized, we'll be able to unlock parallel efforts of optimizations and improvements. One of the big challenges I have today is to break down Embeddables and Inheritance across the board. I have a detailed plan on how to build them, but the amount of interdependencies are preventing me to start this work. Working on ClassMetadataFactory will help reducing most of them.
I've been discussing extensively of having improved Metadata implementors as a way to strategically optimize code that is duplicated across the board on
We made a decision of trying to ditch
I'll attempt to keep this issue with some background information, but ORM.NEXT project is the way to get a more accurate status of the project.
@guilhermeblanco would crowdfunding or sponsoring help in any way, or are you committed to some kind of full-time job (i.e. can money help free some time for you)? Given how widely used Doctrine is, I think a few companies and individual could help financially.
@mnapoli we discussed crowdfunding a few times, but never got to actual concrete details.
If that fails, I'll probably catch up with the rest of @doctrine/doctrinecore and set up a non-profit organisation for Doctrine, so that we can accept funding.
Yeah, but since Doctrine isn't a legal organisation yet, we'd first need to go through that step.…
On 12 Apr 2017 21:53, "Phil Stephenson" ***@***.***> wrote: I've heard good things about https://www.patreon.com/ as well to help with sustainable contributions. I believe Laravel uses this and I'm sure a number of other open source projects. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#6211 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAJakPvwXGcg2VrwJNnGYSStErazF1Iqks5rvSu9gaJpZM4LZrXN> .
@Ocramius I'd suggest taking steps and setting up infrastructure for that. Doctrine is a huge and very popular project that is one of the pillars of the PHP world. If somethong happens to it, it's gonna be a mess, especially if it results in project splitting into forks and all that stuff. There also needs to be a knowledge base built up and docs really need a lot if work (they are vague in a lot of places and sometimes you can't even understad the params of some methods even looking into the code)