-
Notifications
You must be signed in to change notification settings - Fork 346
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
Any plan to make a new release? #2192
Comments
The plan was to release 1.9 as soon as we're confident we have PHP 8.2 compatibility. We run all our own apps on develop code ( we eat our own dogfood 🤣 ) and on PHP 8.2, but as there are parts of the framework we don't use outselfs, we are reluctant to release a new version, with the chance of being covered by complaints when people start upgrading. Any help with establishing this compatibility is much appreciated. |
Hi all, |
We've started to move internal app development to 8.3-RC, We've tested what we've could, and haven't bumped into any 8.x related issues for a while, but we probably don't use 100% of the code. So if you could move your development to 8.2 and report back. much appreciated. As to deprecation, the plan was to release 1.9 with support for PHP 8.0+(so dropping formal support for PHP 5.6 and 7.x), but I don't want to introduce incompatibilies if that isn't absolutely needed, I want the codebase to remain backwards compatible. |
which parts? |
No, not really. It is a big pain tests aren't complete, we had to do without for a while now as we haven't found a way to make phpunit install and run on any PHP version from 5.6 to 8.2, there isn't a compatible version, and we haven't had time to setup virtual machines for each of the PHP versions currently supported, and fix it. We run all our app development on the current develop branch, and on the develop code when the app goes into production. We currently run our apps in development on PHP 8.2, in production on PHP 8.1. So every issue we encounter we fix, but obviously we don't touch the code the app doesn't use. I think quite a few of the issues that will emerge are related to app code, not to framework code.. For example, PHP 8.x is a lot stricter with data types passed to built-in methods and functions. Where PHP 7 would remain silent when for example passing NULL to strpos(), PHP 8 with throw an error saying a string is required. I don't think the framework should fix this, as that would re-introduce "type magic" that PHP itself is trying to get rid of. |
hm, maybe you thought of that yourself and i'm thinking way too simplistic but why not use docker instead of VMs? fire up the php container, install the framework, add the correct version for the specific php version of phpunit on the fly with |
All ten and six pence... ;-) Creating VM's (or Docker or k8ts) isn't the work, figuring out which phpunit version supports what, where to get that version (as no longer available in feeds anywhere), creating a common config that works for all phpunit versions, updating the tests so they run in all phpunit versions (as there are incompatiblilities), and so on. It will be a lot simpler that say "Fuel only runs on PHP 7+ and is only tested on PHP 8+" when releasing 1.9. Given the fact that everything older han 8.0 is already end-of-life and should not be used in production anyway. But that still means quite a bit of work, to get the current tests working on PHP 8 with a recent PHPUnit, and add additional test coverage because that is very poor in some area's. If possible at all, due to the static interface Fuel uses. |
Our app used by thousands of people are using PHP8.3 and version 1.9. I just got my first commit for 8.3 in the pull request section. We'll do more commit if our App reports bugs from these. |
Not sure what you mean, but we've been running all our apps on 8.3 since that was released. The last commit was for the seldon used FTP library, which we missed when we checked. |
That's good to head @WanWizard. Our system running 1.9 and 8.3 seems pretty stable since we migrated 3 days ago. Though, migrating from 7.4 to 8.3 is a little bit painful if you have a big code based. |
Could be worse, I'm having a client app here that we host, that was written for 5.4., which needs to be upgraded to at least 7.4, as that is the minimum version avaialble on RHEL9 (the platform we host on). |
Hello,
I really like this framework and made a bunch of still in use application/website. I saw a lot of commit recently and some of them port and fix issues with php8.*. Do you have any plan to tag a new release to update existing project using composer? Or method to use the code from git?
If help is needed, I can try my best to help with this!
Thanks!
The text was updated successfully, but these errors were encountered: