Allow versions above php 7 for php 8 compatibility

[mycarrysun]

Currently it is not possible to install while using php 8

Problem 1
    - dingo/api v3.0.5 requires php ^7.2.5 -> your PHP version (8.0.0) does not satisfy that requirement.
    - dingo/api v3.0.4 requires php ^7.2.5 -> your PHP version (8.0.0) does not satisfy that requirement.
    - dingo/api v3.0.3 requires php ^7.2.5 -> your PHP version (8.0.0) does not satisfy that requirement.
    - dingo/api v3.0.2 requires php ^7.2.5 -> your PHP version (8.0.0) does not satisfy that requirement.
    - dingo/api v3.0.1 requires php ^7.2.5 -> your PHP version (8.0.0) does not satisfy that requirement.
    - dingo/api v3.0.0 requires php ^7.2.5 -> your PHP version (8.0.0) does not satisfy that requirement.
    - dingo/api v3.0.4 requires php ^7.2.5 -> your PHP version (8.0.0) does not satisfy that requirement.
    - Installation request for dingo/api ^3.0 -> satisfiable by dingo/api[v3.0.0, v3.0.1, v3.0.2, v3.0.3, v3.0.4, v3.0.5].

[maicol07]

This also needs my PR: dingo/blueprint#86

In the meantime, I've joined the two PRs in a repo, so you can add that to composer repos: https://github.com/maicol07/api

[EntonoX]

Can someone merge this pull-request? @specialtactics ?

[RacontR]

Hey there, any update on this ? In advance THANKS ;)

[EntonoX]

@RacontR (and everyone who's interested) I had contact with @specialtactics and the case is; This package relies on CirclecCI, which policy has been updated latetly. Therefore the original creator / maintainer of this package needs to do some setup work to enable other users to merge pull-requests. But... the original creater / maintainer can't be reached so this package seems to be in a sort of locked position.

After some nice communication with @specialtactics he explained that this package is already behind on some plugins like rate limiting etc. in comparison with for example the latest Laravel version. So to keep with modern day situations a extensive rewrite is needed. (correct met if i'm wrong @specialtactics )

Therefore i would advise anyone not to use this package for new projects and try to migrate to other packages.

For me personally; i'm using Lumen framework and switched to 'spatie/laravel-fractal' for transformer support, 'zircote/zwagger-php' for api documentation, and using the Lumen own routing with a self build version middleware (easy).

[codeliter]

How about we Fork it and rewrite it having bumped it up to support PHP 8 @EntonoX

[RacontR]

@RacontR (and everyone who's interested) I had contact with @specialtactics and the case is; This package relies on CirclecCI, which policy has been updated latetly. Therefore the original creator / maintainer of this package needs to do some setup work to enable other users to merge pull-requests. But... the original creater / maintainer can't be reached so this package seems to be in a sort of locked position.

After some nice communication with @specialtactics he explained that this package is already behind on some plugins like rate limiting etc. in comparison with for example the latest Laravel version. So to keep with modern day situations a extensive rewrite is needed. (correct met if i'm wrong @specialtactics )

Therefore i would advise anyone not to use this package for new projects and try to migrate to other packages.

For me personally; i'm using Lumen framework and switched to 'spatie/laravel-fractal' for transformer support, 'zircote/zwagger-php' for api documentation, and using the Lumen own routing with a self build version middleware (easy).

Thank you for the answer and taking the time ;)

[EntonoX]

How about we Fork it and rewrite it having bumped it up to support PHP 8 @EntonoX

Unfortunately i don't have the time on my hands right now to support a new development. (to many private projects in my spare time :), you get the idea ) But personally i think using the mentioned packages you are safer on long time support.

[codeliter]

How about we Fork it and rewrite it having bumped it up to support PHP 8 @EntonoX

Unfortunately i don't have the time on my hands right now to support a new development. (to many private projects in my spare time :), you get the idea ) But personally i think using the mentioned packages you are safer on long time support.

Thanks. I can't even use the new packages because I will need to rewrite all my projects heavily. I will just stay with php7.4-fpm

[Endy-c]

This also needs my PR: dingo/blueprint#86

In the meantime, I've joined the two PRs in a repo, so you can add that to composer repos: https://github.com/maicol07/api

Currently it is not possible to install while using php 8

Problem 1
    - dingo/api v3.0.5 requires php ^7.2.5 -> your PHP version (8.0.0) does not satisfy that requirement.
    - dingo/api v3.0.4 requires php ^7.2.5 -> your PHP version (8.0.0) does not satisfy that requirement.
    - dingo/api v3.0.3 requires php ^7.2.5 -> your PHP version (8.0.0) does not satisfy that requirement.
    - dingo/api v3.0.2 requires php ^7.2.5 -> your PHP version (8.0.0) does not satisfy that requirement.
    - dingo/api v3.0.1 requires php ^7.2.5 -> your PHP version (8.0.0) does not satisfy that requirement.
    - dingo/api v3.0.0 requires php ^7.2.5 -> your PHP version (8.0.0) does not satisfy that requirement.
    - dingo/api v3.0.4 requires php ^7.2.5 -> your PHP version (8.0.0) does not satisfy that requirement.
    - Installation request for dingo/api ^3.0 -> satisfiable by dingo/api[v3.0.0, v3.0.1, v3.0.2, v3.0.3, v3.0.4, v3.0.5].

You guys might not simply change that requirement without any code fixing and test.

In my test, it has conflict with PHP8 in dingo/api/src/Exception/Handler.php:374

    return $exception->getClass()->getName();

must be change to

    return $exception->getType()->getName();

because method getClass has been deprecated in PHP8.

[specialtactics]

Hi, @RacontR I didn't say that I don't recommend for anyone to use this package, there is no issue with using dingo/api, and we can definitely support PHP 8, and continue to support the functionality for as long as we need it.

But the testing is a real issue, because the integration with travis-ci is broken. The easiest thing to do would probably for me to use my own fork and then just merge it to this repo for people using it.

[specialtactics]

I've merged the PR, but will need to do further testing before tagging it, for example that comment above.

Stay tuned, and meanwhile please feel free to use any forks as needed, thanks for everyone contributing to this project!