migration_path.md

Wrapper - Rollouts SDK

import OptimizelyManager from '@optimizely/optimizely-rollouts-sdk';
OptimizelyManager.configure({
  sdkKey: 'Ly8FQj6vSaDcZUjySoWnWz'
})

const optimizely = OptimizelyManager.getClient();
const enabled = optimizely.isFeatureEnabled('sale_price');

Optimizely Deployments

• When deploying any new version of the SDK, we would have to redploy the manager and duplicate the change log between them.
• This would add logistical overhead to our sdk deployments.
• But customers would only have to bump one package

Customer Migration Path

Assuming the manager and the SDK have the exact same API, you would:

1. Change the name from @optimizely/optimizely-rollouts-sdk to @optimizely/optimizely-sdk

Pros

• We can name the SDK so that it's clear rollouts users use the rollouts SDK
• Bumping only one package

Cons

• We won't have a rollouts-sdk for every customer on April 9th, which is really confusing, unless we deploy all the sdks today as rollout-sdks
• It could be possible that the rollouts version could diverge from the sdk version
• (ex: If you were using 4.5 rollouts-sdk, migrate to 3.5 optimizely sdk)
• Benefits we make to the rollouts SDK won't be obviously available for our paying customers

---

Wrapper - Wrapper SDK

import OptimizelyManager from '@optimizely/optimizely-manager';
OptimizelyManager.configure({
  sdkKey: 'Ly8FQj6vSaDcZUjySoWnWz'
})

const optimizely = OptimizelyManager.getClient();
const enabled = optimizely.isFeatureEnabled('sale_price');

Optimizely Deployments

(same as above)

Customer Migration Path

(same as above)

Pros

(other than those listed above)

• Benefits both non-paying and paying customers because it's not clearly just for rollouts users
• Less confusion around not having a rollouts-sdk per language, or duplicate sdk per language.

Cons

(same as above)

---

Manager

import OptimizelySdk from '@optimizely/optimizely-sdk';
import OptimizelyManager from '@optimizely/optimizely-manager';

OptimizelyManager.withSdk(OptimizelySdk);
OptimizelyManager.configure({
  sdkKey: 'Ly8FQj6vSaDcZUjySoWnWz',
})

const optimizely = OptimizelyManager.getClient();
const enabled = optimizely.isFeatureEnabled('sale_price');

Optimizely Deployments

When deploying a new version of the SDK, we don't have to deploy the manager

Customer Migration Path

Assuming the manager and the SDK have the exact same API:

1. Replace to two imports with

import { OptimizelyManager, OptimizelySdk } from '@optimizely/optimizely-sdk';

If the OptimizelySdk decides not to export a true OptimizelyManager you would have to:

1. Remove the OptimizelyManager import
2. Change all instances of OptimizelyManager to OptimizelySdk

Pros

• The user manages the SDK version as they manage the SDK version today

1. Major bump has to require an upgrade of the package
2. Minor bump can get automatically included
3. Patch bump gets automatically included

Cons

• Optimizely has to worry about the SDK versions diverging and there being incompatibility between the manager and client
• User has to also manage the version of the manager, so if we make major bumps on the manager, you have to do those as well.