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

Improvement Request: update some endpoints to newest scope #323

Closed
theca11 opened this issue Jan 17, 2022 · 3 comments · Fixed by #343
Closed

Improvement Request: update some endpoints to newest scope #323

theca11 opened this issue Jan 17, 2022 · 3 comments · Fixed by #343
Labels
Milestone

Comments

@theca11
Copy link
Contributor

theca11 commented Jan 17, 2022

Last February, 3 API endpoints were updated to use the channel:manage:broadcast scope. Even though the old user:edit:broadcast is still valid, it may be a good idea to add the new scope too, as it's indeed usable and the official Twitch docs refer exclusively to it (and so it may be confusing for some users expecting it to work)

For reference, extracted from Twitch Changelog (2021-02-26):

The following endpoints were updated to use the channel:manage:broadcast scope. The previous scope remains valid.

Modify Channel Information
Create Stream Marker
Replace Stream Tags

@d-fischer
Copy link
Member

This is a breaking change and could only be made available using a configuration option, probably on the methods themselves, defaulting to the old scope.
That default could then be changed in the next major version, to adhere to SemVer properly.

@theca11
Copy link
Contributor Author

theca11 commented Jan 17, 2022

Better late than never :D It's a pity we missed the 5.0 release for this change
Still not a super important thing since the old scope is valid, but I guess it will be deprecated at some point

@TheOct0
Copy link

TheOct0 commented Feb 22, 2022

May I try my hand at making this change via a PR?
I'm trying to become more active as a developer outside my own projects, and I feel this could be a good first pull request for this.
I believe the best way to go at this would be to make it an option when creating a new ApiClient. We could make it so that, if a certain argument is passed when using the constructor, all the subsequent method calls from this object would use the new scope, instead of the old one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants