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

PHP 8.3 compatibility checks. #608

Merged
merged 2 commits into from Dec 7, 2023

Conversation

rajeshreeputra
Copy link
Contributor

No description provided.

@rajeshreeputra rajeshreeputra force-pushed the php-8.3-compatibility branch 4 times, most recently from a4547b9 to f550b5f Compare August 24, 2023 07:06
@rajeshreeputra rajeshreeputra mentioned this pull request Aug 24, 2023
.github/workflows/build.yml Outdated Show resolved Hide resolved
@@ -18,7 +18,7 @@
],

"require": {
"php": "^7.2 || 8.0.* || 8.1.* || 8.2.*",
"php": "^7.2 || 8.0.* || 8.1.* || 8.2.* || 8.3.*",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Merging this is a no-go until PHP 8.3 is released as it would block us from doing releases. As said in #607, the way to try the PHP unreleased version is to use the --ignore-platform-req=php+ option of composer.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@stof out of curiosity: why adding constraint for the next PHP version blocks the releases? 🤔

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because for a mocking library, making a release that marks a PHP version as supported while it does not mock properly the code for the new version is a very bad idea.
As a mocking library, new language features often require adapting the library (and so are kind of BC breaks for us).

For devs wanting to try pre-release versions of 8.3, composer already provides exactly the feature you need for that (and testing newer PHP versions is the exact reason why this feature was introduced in composer, so it is the intended usage)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you very much for the explanation, totally makes sense 👍.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@stof, happy to share that 8.3 is now released ;)
but I bet you already aware ;)

@@ -49,7 +49,7 @@ jobs:
- name: Set up PHP
uses: shivammathur/setup-php@v2
with:
php-version: "8.2"
php-version: "8.3"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would not make phpstan run on an unstable PHP version as it increases the risk of having issues in phpstan itself.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

update to run on 8.2 and 8.3 both

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there is no reason to run phpstan on 2 different PHP versions IMO, except wasting compute resources for each CI build.

@glo71317
Copy link

@stof Any plan to merge this PR because we are blocked due to this dependency in our code base.

@stof
Copy link
Member

stof commented Nov 10, 2023

@glo71317 my previous review comments are still relevant. We won't be releasing a version saying PHP 8.3 works right now. To try RC versions, the way to go is to use --ignore-platform-req=php+

@kylekatarnls
Copy link

It's released for a week now, this package is the only one still blocking to upgrade PHP without work-around at the moment some of the projects I work on. 🙏

@kylekatarnls
Copy link

kylekatarnls commented Nov 29, 2023

On another note, waiting for a PHP version to be stable-release to support it in a library sounds ultra-drastic to me. Most of the libraries just test in advance coming versions to ensure they are compatible, most of them also use range such as ^8.1 that just allow whatever <9 and depending on how deprecation are anticipated (for instance adding 8.4 to Github Actions now allow to test with the dev branch of PHP and detect incompatibility ahead before it can impact users of the library), updating can be actually smoother with a major range compatibility.

I don't say it's the only way, just raising alternatives in case it were not investigated in details.

@stof
Copy link
Member

stof commented Nov 29, 2023

@kylekatarnls See my previous comment in #608 (comment) about why using ^8.1 is not an option for Prophecy.

And for testing the dev branch of PHP, I already highlighted multiple times the --ignore-platform-req=php+ option of composer which is precisely about allowing such testing.
Note that for a mocking library, running our existing testsuite on a new version of PHP is not enough to know that we support the new version (this generally goes well). The complex part is figuring out whether mocking classes that use the new features of the language works well.

@Wirone
Copy link
Contributor

Wirone commented Nov 29, 2023

@kylekatarnls PHP is not SemVer, so using open constraints like ^8.1 is discouraged, especially for mocking library that needs to be up-to-date with language's syntax and features.

@stof but wouldn't it be possible to prepare internal test cases that just utilise PHP 8.3 features and verify if everything works? In Fixer we also don't use PHP 8.3 features (code is 7.4-compatible), but we have integration test that verifies if fixer properly fixes files with 8.3 syntax. Is it possible in Prophecy to prepare such tests?

@stof
Copy link
Member

stof commented Nov 29, 2023

@Wirone The issue is that since months that we said that this is the kind of checks that are needed to be able to know whether PHP 8.3 works fine (see #607), nobody in the community made such tests (or at least nobody reported the result to the repo if they tried it in separate codebase). It is not that it is not possible to do it. The issue is that it is not done.

@maxhelias
Copy link

I use the --ignore-platform-req=php+ option on phone-number-bundle to get the tests on the development version : https://github.com/odolbeau/phone-number-bundle/blob/master/.github/workflows/tests.yml#L27
Of course, there aren't many tests, but we have nothing to report on prophesize.

@stof stof merged commit 03cfe36 into phpspec:master Dec 7, 2023
9 checks passed
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

Successfully merging this pull request may close these issues.

None yet

7 participants