:warning: The Truffle Suite is being sunset. For information on ongoing support, migration options and FAQs, visit the Consensys blog. Thank you for all the support over the years.
The only code change will be flipping enabled in the config to true.
However, VC will need to check for existing config files whose lastVersion is >= the deployment semver for VC and <= activation semver of VC. These VC config files will already exist on the user's disk and have enable set to false. VC will not clobber an existing config. So these users upgrading to an activated version of ganache will never enable VC.
Additional code will need to check for these config files, enable them, and add a new default value to the config didActivate: true. This additional code will ignore any config files with an existing didActivate: true.
At some future date, the activation code may be pruned from VC.
Additional Explanation
Use Case:
User installs a version of ganache prior to VC deployment then upgrades to Use Case 2 or Use Case 3.
User installs or upgrades to a version of ganache after VC deployment, but before activation.
User installs or upgrades to a version of ganache after VC deployment and after VC activation.
Use Case 3 has no existing config file. VC deploys activated, no additional work needed.
Use Case 2 has an existing config file with enable false and lastVersion in a range VC Deployment Semver <= lastVersion <= VC Activation Semver. We are probably ok basing this check on lastVersion since it will update, but we only want it to run once, ever. And we don't want it clobbering configs every time the VC Activation Semver version is the edge case that would overwrite a user who would disable VC after it activates itself. We don't want to start a tug of war with the user. So the addition of a didActivate: true value to the config is recommended with VC activation ignoring config files with this value.
Once we are satisfied some timeline has passed that the users in Use Case 2 have upgraded to a version that self-activates date we are safe to prune the activation code out and didActivate value from the config.
This code could be part of the deployed VC code and we would have an assurance that Use Case 2 users would activate once, even at the lower version. We could then prune the activation code at the time VC activates since it would live in the older versions installed on user devices.
VC will deploy disabled.
At a future release, we will activate it.
The only code change will be flipping
enabledin the config to true.However, VC will need to check for existing config files whose
lastVersionis >= the deployment semver for VC and <= activation semver of VC. These VC config files will already exist on the user's disk and haveenableset to false. VC will not clobber an existing config. So these users upgrading to an activated version of ganache will neverenableVC.Additional code will need to check for these config files, enable them, and add a new default value to the config
didActivate: true. This additional code will ignore any config files with an existingdidActivate: true.At some future date, the activation code may be pruned from VC.
Additional Explanation
Use Case:
Use Case 3 has no existing config file. VC deploys activated, no additional work needed.
Use Case 2 has an existing config file with
enablefalse andlastVersionin a rangeVC Deployment Semver <= lastVersion <= VC Activation Semver. We are probably ok basing this check onlastVersionsince it will update, but we only want it to run once, ever. And we don't want it clobbering configs every time theVC Activation Semverversion is the edge case that would overwrite a user who would disable VC after it activates itself. We don't want to start a tug of war with the user. So the addition of adidActivate: truevalue to the config is recommended with VC activation ignoring config files with this value.Once we are satisfied some timeline has passed that the users in Use Case 2 have upgraded to a version that self-activates date we are safe to prune the activation code out and
didActivatevalue from the config.This code could be part of the deployed VC code and we would have an assurance that Use Case 2 users would activate once, even at the lower version. We could then prune the activation code at the time VC activates since it would live in the older versions installed on user devices.