Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create DLLs for Phalcon 3.x and PHP 7.3 #13847

Closed
sergeyklay opened this Issue Feb 20, 2019 · 12 comments

Comments

Projects
None yet
6 participants
@sergeyklay
Copy link
Member

sergeyklay commented Feb 20, 2019

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.
Many people might consider using/migrating to Phalcon 4 only when it gets stable and probably waiting for some more first Bugfix releases. Until this happens my personal guess is, there will already be php 7.3.10+ around.
My boss would tell me to drop phalcon then (a new project to migrate to phalcon 4 someday had to be made anyway, so my boss would argue to switch back to a raw php framework if that's the only way to be able to use the latest php version.

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.
. I currently had no luck by simply googling it.. 🙂

Originally posted by @lubber-de in #13511 (comment)

@sergeyklay

This comment has been minimized.

Copy link
Member Author

sergeyklay commented Feb 20, 2019

@sergeyklay sergeyklay referenced this issue Feb 20, 2019

Merged

Add PHP 7.3 support #13511

2 of 3 tasks complete
@ruudboon

This comment has been minimized.

Copy link
Member

ruudboon commented Feb 20, 2019

Is it aready clear what needs to be done to support 7.3 under 3.4.2?

@sergeyklay

This comment has been minimized.

Copy link
Member Author

sergeyklay commented Feb 20, 2019

In general no. l'll research on that.

@david-duncan

This comment has been minimized.

Copy link

david-duncan commented Feb 20, 2019

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.

@niden

This comment has been minimized.

Copy link
Member

niden commented Feb 20, 2019

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

/0.02 USD

@lubber-de

This comment has been minimized.

Copy link

lubber-de commented Feb 20, 2019

@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)
Only the current php 7.3 (or 7.4,8.0..depends how quick phalcon 4 gets official stable) is missing

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)
For new projects nobody will choose a framework which is currently its its alpha stage, supposed not to be backward compatible and supposed to still change class and function syntax with unknown date of stability.
We can work fine with the "old" 3.4 branch but not of costs of not being able to use the latest php versions anymore. You have the chance to keep phalcon alive.
Breaking changes for a major version upgrade like 4.0 is totally fine, also to say only the latest version is supported... But it would have to be stable then at least. Until then the latest version should always work. Otherwise, people are going to abandon it and going back to Symfony, laravel, whatever...
Because a new project to upgrade legacy applications has to be done anyway. But project managers won't bet on phalcon 4 in its current stage.... 🙂

@niden

This comment has been minimized.

Copy link
Member

niden commented Feb 20, 2019

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

@sergeyklay

This comment has been minimized.

Copy link
Member Author

sergeyklay commented Feb 20, 2019

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.

@david-duncan

This comment has been minimized.

Copy link

david-duncan commented Feb 20, 2019

@niden

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.

@dschissler

This comment has been minimized.

Copy link
Contributor

dschissler commented Feb 21, 2019

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.

[edit] 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.

@niden

This comment has been minimized.

Copy link
Member

niden commented Feb 21, 2019

@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 Upgrade Instructions link top right
https://docs.phalconphp.com/4.0/en/upgrade#filter <- Upgrade doc with affected areas
https://docs.phalconphp.com/4.0/en/installation <- Installation

Any feedback on the docs is of course more than appreciated.

sergeyklay added a commit that referenced this issue Feb 24, 2019

@sergeyklay

This comment has been minimized.

Copy link
Member Author

sergeyklay commented Feb 24, 2019

This has been addressed: https://github.com/phalcon/cphalcon/releases/tag/v3.4.3

@sergeyklay sergeyklay closed this Feb 24, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.