Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Create DLLs for Phalcon 3.x and PHP 7.3 #13847
This issue was created from the issue's comment in #13511
@sergeyklay Thanks for clarification. But as phalcon 4 won't be stable soon and more important won't be backward compatible to 3.4, I highly suggest that you at least think about making 3.4.2 php 7.3 compatible without any other fixes or features (that's what phalcon 4 is for) . Otherwise many teams will be either stuck on php 7.2 or have to migrate their existing and working projects to the phalcon 4 which is probably a lot of effort also because much stuff has been removed, so it's not only renaming some method calls. The main point is that php 7.3 is stable and released while phalcon 4 is not. So currently there is no combination of both libraries in stable condition. You should support the current php version for the 3.4.x branch at least until phalcon 4 is stable IMHO.
Don't get me wrong, I really like what you are doing and you are doing it great! Just think about it again
Anyway, I read somewhere somebody got a working 3.4.2 windows DLL for php 7.3. So, even if phalcon is not officially supporting it, I would love if you could point me to a download link. Then my concerns might be completely gone and looking forward to a phalcon 4 upgrade can be planned in a more relaxed way.
Just wanted to chime in -
I'd like to see 3.x support 7.4 and 8.x
From what I can tell, the 4.x branch has a lot of unnecessary churn without providing anything new of value. I understand technical debt and the need to reduce it, but I don't see anything additive or worthwhile to spend the time migrating from 3.x to 4.x.
I've watched this project die a slow death for 5 years now. @sergeyklay and @niden are the only ones left remaining, and you guys look like you are pretty busy with your day jobs. Adding new features that are worthwhile is a pretty big task, and I feel you should spend your energy on compatibility and future thinking with PHP, instead of trying to continue this project on as a competitive framework.
In short - I see this project dying even more if you require the massive upgrade from 3.x to 4.x just to get access to 7.4 and 8.x. The only reason we still use Phalcon is because the cost to migrate some legacy applications from PHP is too high.
Additionally - You guys really need to clean up the issue tracker. There are a lot of nonsense NFRs creating noise. It is better to be judicious and close, than to be passive and let it expire with the stale bot.
@david-duncan I don't disagree with much of what you said, but here is my 2 cents.
Yes there are 2 of us for now. There are some contributors here and there which definitely helps and we have been actively trying to hire C developers to help with the Zephir part of things. That is ongoing and results cannot be seen immediately of course.
Now for v3/v4. Keeping v3 alive and piling up more and more things in it is a recipe for disaster. v3 supports PHP 5.x vs 4 does not. If we keep on working on that version that means that we will have to keep "split" code i.e. have conditionals for php 5 and php 7. DLLs for php 5 are a pain and have been a pain since we started working with php 7.
v3 lacks a lot of structure that would allow us to expand more. I will give you a small example : PSR. We wanted for quite a long time to follow these standards and even introduce say middleware to the full application. Currently we cannot because certain steps need to be taken before anything else can be done. Certain components need to be slowly deprecated etc. (we have SemVer to keep in mind). Maintaining 2 versions will not allow us to do pretty much anything else - we will be mostly maintaining a version that does not allow more growth and new features.
So we need to stop working on v3 and keep it as is, and start using v4 once it goes out with mostly structural changes. This will allow for a good base to work on and expand for v5 etc.
Yes if you look at v4 there is not that much "new" stuff there. This was renamed to that, the calls to X changed from a to b etc. However structurally a lot of things are changing to make us work a lot better and faster. One of the goals for instance is to set up a container to do auto discovery. Doing that will be a step forward but this cannot be done from one version to another, we need to keep both containers for at least v4 and deprecate the old DI later on (or keep it if the community wants it).
For the issue tracker, this is work in progress. I do agree that there are a lot of NFRs there that we might not even want to tackle. Someone posted a suggestion to set some sort of voting process to give each NFR a "weight" based on what the community wants. For now anything that was marked as bug has been in the v4 project and is currently in the queue to be addressed.
@niden well, as I mentioned above, I don't expect 3.4.x to receive any new features. Therefore you can even drop all php 5 support (because there already exist working version for those php versions)
I suggest to freeze features for 3.4.x and only make adjustments to the 3.4 branch if new php versions need it to work as it was before(which is currently the case for 3.4)
@lubber-de PHP 7.4 is not ready yet. Phalcon will always be a bit behind each version because first we need to check the impact that any new php version has to the generated C code and then adjust Zephir accordingly if need be. The plan though is to offer 7.4 support as fast as we can and there is some work that has already been started. We are trying not to do what we did with php 7 support - i.e. delay and delay even more. See comment above about finding and hiring C programmers to aid with Zephir.
Nobody is expecting new projects to adopt a version that is alpha only. Since v4 has not been released and still in alpha, it is a version for people to test and see what the upgrade cost will be when that version becomes stable.
If we are to offer support for 7.3, 7.4, 8.0 for v3, that means that we will have to keep that version stable and production ready, fixing bugs etc. that will come with the support for the new PHP versions (since we all know no software is bug free). That removes time and effort from v4 and moving the framework forward with new features.
Okay guys. I'll try to sort out this weekend. I hope that everything will work out for me, because the current C code needs to be regenerated from Zephir, and I will also have to make some changes to the build system for 3.x. I cannot guarantee that everything will work out right away, but I will try.
I appreciate the great response. I try to keep all of my feedback as positive as possible and I definitely appreciate the time that you and @sergeyklay donate.
I understand the cost of bifurcating your time between branches and I know why you are advocating a strong path towards 4.x.
I know its hard to try and prioritize volunteer time, but my last suggestion is to minimize the number of things that will require adoption 4.x to be difficult, and help focus efforts on what matters like mentioned (removing backwards compatibility to improve code agility, supporting future PHP versions to ensure adoption).
Lastly - If you guys could divide up tasks or get an SOP (or link to one) for upgrading phalcon/zephir against new target versions of PHP (7.4 / 8.x) that would help advanced users like @virgofx, @dschissler and myself to help contribute.
Some teams like to test against beta / release candidates well in advance, to anticipate and properly schedule changes that they will encounter down the line.
I've been resistant to positivity after watching California slowly go to shit over my lifetime by doing just that. Phalcon rotted for many years without hardly an unpleasant word in public. Most of all Phalcon needs passion now and if consistent positivity is also a requirement then I might as well exclude myself out already. I reserve the right to spend long night boozing and whoring and if in the after hours I look at some shit code or design pattern then I'm going to feel how I feel as all great artists do.
In regards to Phalcon 3.4 and PHP, I think that there simply needs to be a Phalcon 3.5. The reason is that you just can't discontinue PHP less than 7.2 support on a Phalcon version that already has it and you can't add new PHP support to it without fucking up modern Zephir. So in say 6-9 months offer an extended Phalcon 3.5 version with only PHP 7.2, 7.3 and 7.4 (no 5 or 7.1). Then simply let people know that only serious blockers will be fixed. Sergei can just copy paste the latest Phalcon 4.x build stuff into the 3.5 branch to get that current. I think that this is necessary because the timing of the Phalcon 4 branch was not executed perfectly. If Phalcon can commit to this then it frees up the team to implement Phalcon 4 in the most ideal way possible going forward. In the meantime any lapse of PHP support in Phalcon 3 can be explained away as "working on it" and that is already something people are accustomed to accept. This frees up the energy to work on Phalcon 4 and then to do documentation and other transitions. Then the Phalcon 3.5 is rolled out and hey what great guys we are for honoring our LTS pledge.
 I'm not thinking about adding really any features to Phalcon 3.5. If anything it would be an opportunity to back-deprecate changes that we already made in Phalcon 4.0. I feel like then we can just do 4.0 how we want without having to get bogged down in the deprecation. So bleeding edge adopters of 4.0 just need to know how to upgrade from the change log and blog entry whereas the Phalcon 3.5 users would get some deprecation warnings.
@david-duncan Thanks for the comment. Regarding the upgrade have a look at these links (work in progress of course)
https://docs.phalconphp.com/4.0/en/filter <- check the
Any feedback on the docs is of course more than appreciated.
added a commit
Feb 24, 2019
referenced this issue
Feb 24, 2019
This has been addressed: https://github.com/phalcon/cphalcon/releases/tag/v3.4.3