Relaxed version constraint to allow v7.3 of oauth2-server

[gschafra]

v7.3.0 of oauth-server does not seem to introduce breaking changes. Call of finalizedScopes() (see ScopeRepository) was moved, see https://github.com/thephpleague/oauth2-server/blob/master/CHANGELOG.md#730---released-2018-11-13

[X-Coder264]

league/oauth2-server uses semantic versioning to manage version numbers so is there any reason why we shouldn't write the constraint as just ^7.2? Otherwise a similar PR will have to be sent after each new minor version gets released in the 7.x series.

[gschafra]

In fact I've considered using ^7.2. But since the last build failed with

1) App\Tests\Acceptance\TokenEndpointTest::testSuccessfulClientCredentialsRequest
Failed asserting that 3599 is identical to 3600.

I'm no longer sure, if backward compatibility is really ensured within minor version change from v7.2 to 7.3 in leage/oauth2-server. But, of course, I also prefer your suggestion. Just and still trying to find out this, which minor change in the leage/oauth2-server causes failing this test.

[spideyfusion]

@gschafra The issue you're describing was fixed today. See #13 for more information. :-)

[codecov-io]

Codecov Report

Merging #11 into master will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master      #11   +/-   ##
=========================================
  Coverage     86.18%   86.18%           
  Complexity      201      201           
=========================================
  Files            37       37           
  Lines           608      608           
=========================================
  Hits            524      524           
  Misses           84       84

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2969907...e5459ea. Read the comment docs.

[spideyfusion]

@gschafra The change looks good, but I have one question for you based on your commits:

How come you decided not to relax the version requirement for the symfony/psr-http-message-bridge package to ^1.0?

[gschafra]

@spideyfusion Kind of conservative attitude of mine. Do you think, it's save and better to allow minor updates on symfony/psr-http-message-bridge? I know, since it's a minor, it should be... so... as soon as you give me an o.k. I will do it.

[spideyfusion]

@gschafra Go for it. Symfony is pretty good at respecting the semantic versioning convention.

[spideyfusion]

@gschafra Thank you for your continued contributions. :-)

[gschafra]

@spideyfusion No problem, thanks for your effort to start this bundle! I'm thinking about to implement symfony command to manage client, like

• trikoder:oauth2:add/update-client --identifier BlaBla --secret 13AB424 --grants...
• trikoder:oauth2:remove-client --identifier BlaBla --secret 13AB424 --grants...

Anyone already planned doing this?

[spideyfusion]

@gschafra Sorry for the late reply. It seems someone had similar thoughts and opened a PR for it (#17). We can continue our efforts there. :-)

[ajgarlag]

Sorry, I started to work with this bundle some days ago and did not see this conversation. I'm happy to contribute with it. I hope your revision on #17.

@spideyfusion Thanks for sharing your great work.