Giters

dolejska-daniel / riot-api

Riot League of Legends & DataDragon API wrappers for PHP7 and PHP8.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

[3.1.0] Conflict with projects using Symfony 4

techiigg opened this issue · comments

commented

Bug description
Laravel has required symfony 4.0 or greater since tag 5.6 (Laravel/Framework 5.6, 5.7, 5.8 and 6.0). They swapped in December 2017
(laravel/framework@eadcabe)

All versions after 3.0.11 will therefore be denied on require or hang (in my case, for a really long time) on composer update.

To Reproduce

  1. Create a symfony 4 project or any Laravel project more recent than 5.6
  2. composer require dolejska-daniel/riot-api

Expected behavior
riot-api should be installed.

Might be as simple as a version bump, but I'm not sure how complex an update from symfony/console v3 => v4 will be.

commented

Hello,

I thought this could be a problem for some people... Update of symfony/console to v4 is as simple as just changing it in composer.json for me, but this version requires PHP>=7.1 and does not accept PHP7.0 anymore.

In that situation this library becomes unusable for people using PHP7.0.

commented

I can definitely understand that point of view. I'll stay 3.0.11 for now and fork it if there's any API changes. Hopefully a symfony 4 version bump will be more appropriate in the future. Thanks for creating and maintaining an otherwise great lib :)

commented

@dolejska-daniel, I'm starting a new project using Symfony 4, and I got this issue. I had to install v3.0.11, but I'm wondering how much of an issue will it become for futur Riot API updates?

I think that if you want to still support PHP 7.0, you will need to maintain two branches?

commented

Hi @hawezo I currently do have two options:

  1. maintain two branches
    one with latest symfony/console allowing only PHP7.1+
    one with older symfony/console allowing PHP7.0+

  2. abandon support of PHP7.0

I guess I can try to support two branches for now having the PHP7.0 branch only to receive necessary API updates and fixes without receiving possible latest library features.

commented

I think supporting the two versions if the best option, but it obviously comes with more work. You can define an end-of-support date, though, so you don't have to endlessly take care of the PHP 7.0 branch and eventually drop it.

Whatever option you chose, thanks for your work :)

commented

Alright guys, @techiigg, @hawezo - you can now use ^v4 as version specification for your Symfony projects. 😄 You will have access to the latest library updates and features and there should no longer be any problem with version collisions of symfony packages.

The PHP7.0 version of the library is now available through the ^v3 version specification. Source is in the v3-dev branch.

commented

Thanks a lot!