Created by: ybelenko
I would even set PHP ^8.1 since it has new key features like union of types public setTarget(SomeClass | AnotherClass $target)
which is very handy to use from the first day. It could also reduce maintain burden(support one version instead of two). But I assume that community wants to cover all current PHP version, so be it "php": ^8.0
.
Related #14152
In the next PR I'm gonna add strict_types
declaration and extend PHP-CS-Fixer
config a lot. It can cause huge PR with huge diffs because it obviously will update code style in all samples.
Also want to add phplint
package for quick syntax check and CI.
Then long refactoring discussed with @wing328. William wants to port fromJson
, toJson
, toDict
, fromDict
methods from python-nextgen
and hide data serialization in ApiClient then user don't need to be aware of ObjectSerializer anymore. My personal goal is to use new PHP features. Second goal is to use interfaces as much as possible, to be more specific I want new php client to be easy configurable via PHP-DI container. Maybe we finally can stop depending on GuzzleClient and use PSR HttpClient interface instead.
I didn't check generated TravisCI config since I don't use it anymore(I like GitHub Actions more recently), but their online compiler says that syntax is correct.
cc @Articus @jebentier @dkarlovi @mandrean @jfastnacht @renepardon
PR checklist
-
Read the contribution guidelines. -
Pull Request title clearly describes the work in the pull request and Pull Request description provides details about how to validate the work. Missing information here may result in delayed response from the community. -
Run the following to build the project and update samples: ./mvnw clean package ./bin/generate-samples.sh ./bin/utils/export_docs_generators.sh
./bin/generate-samples.sh bin/configs/java*
. For Windows users, please run the script in Git BASH. -
File the PR against the correct branch: master
(6.3.0) (minor release - breaking changes with fallbacks),7.0.x
(breaking changes without fallbacks) -
If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.