Do not set the singleton inside init #42
Conversation
This allows one to create a separate client instance without worrying if the client instance will be set as the singleton. The class still supports a singleton, but must be explicitly set. In addition, this uses the instancetype return types for better complier inference.
|
Looks good to me! This is a breaking change, though, so when this is merged we need to do a major version increment. Let's see if we can fit more than just this change into that release to warrant a major version even more. |
|
@asbjornu What else did you have in mind for this next 'major version'? |
|
And was there anything else you'd like done in this PR? |
|
@streeter The PR looks fine. But since it breaks backward compatibility, it warrants a major version increment as per the rules of semantic versioning, which gives us an opportunity to fold other breaking changes into the release. @frewsxcv I'm not quite sure what they are yet, but perhaps @timorzadir has some ideas? |
|
If #44, #45 or https://github.com/getsentry/raven-objc/issues/46 ends up breaking backward compability when they are done, I would like to include that |
|
It looks like all of those issues have stalled. Any chance this could move forward? |
Do not set the singleton inside init
4 participants
This allows one to create a separate client instance without worrying if the client instance will be set as the singleton. The class still supports a singleton, but must be explicitly set.
In addition, this uses the instancetype return types for better complier inference.
Fixes #41