Hello again. Would you please help verify the viability of migration strategy from v1 to v2 SDK dependency? The facts: - We're using GrowthBook 2.9.0, which has v2 hashVersion as the default - And this hashVersion 2 can be verified from the SDK endpoint which has all the features in json - Our current app is using the old version of SDK that only supports v1 - And the assumption is that the allocation right now is only using v1 regardless of the hashVersion 2 in the features json The assumption: - By upgrading SDK to the latest version would mean a breaking change upgrade - Considering the new SDK lib will respect hashVersion 2 in features json - And that could result in different variations for the still-running experiments that was previously running with v1 with the old SDK - Will impact the experiment result The migration steps: - Downgrade to hashVersion v1 for the still-running experiments using GrowthBook REST endpoints, using

PUT /experiments/{id}

with hashVersion 1 - Verify hashVersion 1 is in the SDK endpoint features json - Do a release for the app that's now using latest SDK lib that respects hashVersion 2 - Still-running experiments that was previously using v1 will still be using v1 because hashVersion has been downgraded in the previous step - For subsequent and newly created experiments will have hashVersion 2, and the application will also respect the hashVersion 2 in features json and allocate accordingly

Hi Albert, Good morning and thank you for writing in. Upgrading to GrowthBook version 3.0.0 should not directly affect your running experiments. However, it's always a good idea to thoroughly test the new version in a non-production environment before deploying it to production to ensure everything works as expected. GrowthBook 3.0.0 introduces several new features and improvements, such as Edge SDKs, Bayesian Priors and CUPED, Custom Roles, OpenFeature Support, Experiment Slack/Discord Alerts, JSON Feature Flag Editor, New Next.js Examples, and SDK Updates. These changes should not interfere with your existing experiments, but they may offer new capabilities for your future experiments. Before upgrading, you should review the release notes for GrowthBook 3.0.0 to understand what changes have been made and how they might affect your use of the platform. Here are the steps for updating to version 3.0.0 using Docker: 1. Pull the latest version of GrowthBook using Docker Compose: ​`docker-compose pull growthbook`​ 2. Stop the current GrowthBook container: ​`docker-compose stop growthbook`​ 3. Start the new version of GrowthBook: ​`docker-compose up -d growthbook`​ These commands will pull the latest version of GrowthBook, stop the current running version, and start the new version. For more details, you can refer to the [Updating to Latest](https://docs.growthbook.io/self-host#updating-to-latest) section in the GrowthBook documentation. Please note that before updating, it's always a good idea to check the release notes for any breaking changes or additional steps needed for the update. You can find the release notes for GrowthBook 3.0.0 on the [GrowthBook GitHub page](https://github.com/growthbook/growthbook/releases/tag/v3.0.0). Hope this helps and please let me know if you have any follow up questions related to the above :)

• Hi again @flaky-noon-11399, • the upgrade was not for the growthbook 2.9.0, but rather on the SDK libs used by the applications, • currently using 0.20.1 for the JS SDK, • and 0.5.0 for the Java SDK .. • Hopefully with this new context, re-reading the original post will be more understandable. • Sorry for the confusion !

Hi Albert, ah I see that you for the assisted information. Yes, upgrading the SDK can potentially affect experiments, but GrowthBook takes measures to ensure backward compatibility. This means that all existing experiments and feature flags should continue to work without changes after an SDK upgrade. However, an SDK upgrade can introduce new features and improvements that could affect how you set up and run experiments. Given the above, the migration steps look good to me, but I will get this peer reviewed by the Engineering team to confirm. As soon as i have another pair of eyes on the migration steps I will let you know via this thread. As an added note, it's always a good idea to thoroughly test your experiments after an SDK upgrade to ensure they're still working as expected. You might also want to run an A/A test after setting up a new SDK connection to validate that the experiment data is being sent correctly to your data warehouse.

• Hi @flaky-noon-11399, I really appreciate you following this up. • Applause for the backward compatibility, I'm counting that the v1 allocation algorithm stays the same between the oldest version of the client SDKs and the latest versions .. • And happy weekend from Indonesia !

Thank you Albert and it really is my absolute pleasure to assist!!! Ohhhh Indonesia, how lovely (my bucketlist destination)!! Hope you have the best weekend and I will get back to you as soon as I have an update from the team!! Warmest regards, from London, UK 🌼