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

Custom Variables in 4.x #204

Closed
zantoku opened this issue Nov 23, 2017 · 5 comments
Closed

Custom Variables in 4.x #204

zantoku opened this issue Nov 23, 2017 · 5 comments

Comments

@zantoku
Copy link

zantoku commented Nov 23, 2017

We have a "legacy" project that relies on the use of Custom Variables. We can't readily change to Custom Dimensions, so until now we've been forced to stay on the old 3.x version of the SDK.

However, we really want to move to the 4.x branch of the SDK so we don't run into a situation where the old SDK breaks for some reason and we're left unsupported.

So what I've done is add support for Custom Variables (and improve the ObjC-interop a little), largely following the implementation pattern for Custom Dimensions. Can we contribute the code to the project?

@zantoku
Copy link
Author

zantoku commented Nov 23, 2017

If you want to review the code, I've created a pull request here: #205

@brototyp
Copy link
Member

Hi @zantoku, thanks for your information here and the pull request. I will check it out and see how it fits into the SDK. Generally I am not sure how deprecated features should be integrated into the SDK.

As far as I see there are a few options.

  1. Add them as first class citizens. (This is basically what you did)
  2. Add them as first class citizens but deprecate them right away. (And possibly define a version where it will become unavailable)
  3. Add them as second class citizens, deprecate them and offer them as a part of the core SDK. This could be achieved by adding convenience methods to define customTrackingParameters.
  4. Document a way how it is possible to achieve with the existing SDK (by using the customTrackingParameters for example) but not offering them as a part of the Core SDK.

I think 2 is better than 1, since it shows new users that there is a "better" way to achieve the same. 4 Could be a bit complicated for users that need the same features. What do you think?

@zantoku
Copy link
Author

zantoku commented Nov 29, 2017

Hi @brototyp, seeing as how all the work for option 2 is already done, I'd appreciate if we could proceed with that! :) Do you want me to extend the pull request with deprecation annotations?

@brototyp
Copy link
Member

brototyp commented Dec 3, 2017

Hi @zantoku, I am fine with option two. Can you add the deprecation annotations and a paragraph in the readme?

@brototyp
Copy link
Member

This got implemented and merged in #223. It is be part of the 5.0.0-beta1 release.

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

No branches or pull requests

2 participants