chore: merge ScopeExtensions to Scope #3186
Conversation
|
Are we running the same build twice now after |
vaind
changed the title
| @@ -6,6 +6,10 @@ | |||
|
|
|||
| - Added Crons support via `SentrySdk.CaptureCheckIn` and an integration with Hangfire ([#3128](https://github.com/getsentry/sentry-dotnet/pull/3128)) | |||
|
|
|||
| ### API changes | |||
|
|
|||
| - Removed `ScopeExtensions` class - all the public methods moved directly to `Scope` ([#3186](https://github.com/getsentry/sentry-dotnet/pull/3186)) | |||
There was a problem hiding this comment.
Is that change even visible to users?
There was a problem hiding this comment.
Shouldn't be for c# users
There was a problem hiding this comment.
Their code won't have to change if they're recompiling with the new code. Technically I guess it's not binary compatible (if someone was using reflection to get at these extension methods for some strange reason, that would break)... I'm not sure how hard core we want to be about avoiding breaking changes. @bruno-garcia can we be "pragmatic" here?
There was a problem hiding this comment.
can we be "pragmatic" here?
Yes, especially since this is improving/fixing things on the Powershell side and not just a refactor for fun.
In PowerShell, extension classes are just standard classes with static methods, so you had to do
[Sentry.ScopeExtensions]::AddEventProcessor($scope, $processor)with this PR, you can now:
$scope.AddEventProcessor($processor)