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

Any plan to make a new release? #2192

Open
tete2soja opened this issue Jul 13, 2023 · 11 comments
Open

Any plan to make a new release? #2192

tete2soja opened this issue Jul 13, 2023 · 11 comments

Comments

@tete2soja
Copy link

tete2soja commented Jul 13, 2023

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!

@WanWizard
Copy link
Member

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.

@polmartinez
Copy link
Contributor

Hi all,
I've several applications with 1.9-dev and php 8.0 and 8.1.
I could move some of them to 8.2 and test other functions. There are also things that can be deprecated.
If you need help let me know.

@WanWizard
Copy link
Member

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.

@glOOmyART
Copy link

but as there are parts of the framework we don't use outselfs

which parts?
is there a list of stuff you haven't ported or tested yet?

@WanWizard
Copy link
Member

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.

@glOOmyART
Copy link

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 composer require, run the unit test, output to a file in a local folder and then stop and remove the container

@WanWizard
Copy link
Member

WanWizard commented Oct 2, 2023

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.

@reillo
Copy link

reillo commented May 29, 2024

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.

@WanWizard
Copy link
Member

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.

@reillo
Copy link

reillo commented May 30, 2024

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.

@WanWizard
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants