Closed RobinDaugherty closed 6 years ago
Why don't we instead move sentryApiToken
to optionalConfig
and verify in the setup-step whether either of them is configured?
Then again, if the API token is strictly legacy, then going with the bearerApiToken
forward & releasing 0.6
also makes sense.
@dschmidt your thoughts?
I'm with @duizendnegen here. Why should we break old sentry versions?!
Would be great to move forwards on this one, as the current release is simply broken for new adopters of the plugin.
I suggest that the old version of Sentry doesn't need to be supported in the new version of the plugin. If someone is still running the old version of Sentry, they shouldn't upgrade. Hence the major version bump, assuming that we're following semantic versioning.
Guys, any news on this one? This plugin is actually broken for new adopters. Would be lovely to fix it :)
We are happy to merge in a PR with sentryApiToken
as backward compatibility still being there, in the PR this is completely removed.
Support for bearer tokens was added to the plugin, since that is required for modern Sentry support. But
sentryApiToken
is still required, which makes no sense. There are about 6 forks of the repo solely for the purpose of making this work.I have removed legacy
sentryApiToken
support completely, requiringsentryBearerApiToken
instead. I recommend releasing this with a major version bump, so we can move ahead. Those using the old version of Sentry will need to stick with their old version of the plugin, or update and get a new token from Sentry.