To follow these instructions you will need access to an SDK of the release you want to upgrade to. Unzip the SDK somewhere so you can copy the necessary resources from the new SDK to your current SDK project directory structure.
If you used the Sentinel Installer with your current SDK then it will have
Make sure this file is present in the current SDK in that case to simplify
configuring the new deployment module.
If you have used the
build/bin/go-offline script to take your SDK offline
then you will have to take it online again by running one of the following
commands depending on your current SDK version, as upgrading offline
repositories is not supported:
|SDK version||Command to run|
2.4.0.x and later
If your SDK is not under version control it is recommended to create a backup of the SDK before starting the upgrade process in case something important gets inadvertently deleted. A backup will also allow recreating a deployment module in order to facilitate comparing it with a configured module as explained in Upgrading deployment module configuration.
Upgrading the build infrastructure
The build infrastructure consists of the
build directory and the
file in the SDK root directory.
Replace both of these with the versions from the new SDK.
sdk.properties file contains fundamental properties of an SDK and there
may be important changes between SDK releases.
Since it also contains user-specific properties it cannot simply be replaced
However, depending on your situation the process should still be relatively
The simplest case is that you have not added any custom properties to the file
and are planning to use the installer.
In that case the file can simply be replaced with the version from the new
SDK as all the user-specific properties will be configured by the installer.
The only exception to this is the
branch.name property which you will have
to copy over from the current file in case you changed it.
If you have added custom properties but are still planning to use the
installer then copy those properties to the new file and then use that file to
replace the current one.
As above, you may also have to copy the
If you do not want to use the installer then you will have to copy a few properties to the new file before you can replace the current one, in addition to any custom properties you added. These properties are:
Handling SIS and CGIN upgrades
The new SDK may contain new releases of SIS and CGIN. Unless you are using a custom version of these that you want to continue using, you should remove the current versions so they can be upgraded. This involves two actions:
cgindirectories from the root of the SDK.
cgin.homeproperties from the
Update the CGIN dependency to 188.8.131.52
Update the Cassandra CQL dependency to 184.108.40.206
Update the MMTel Standard Schema dependency to 220.127.116.11
Update the REM dependency to 18.104.22.168
Update the Sh Cache dependency to 22.214.171.124
Update the SIS dependency to 126.96.36.199
Removing out-of-date dynamic content
ivy.properties files are automatically
generated and have to be deleted so they can be regenerated with the correct
values for the new SDK.
If you are upgrading from a 2.3.1 release and you have used the installer then
you will have a directory called
installer in the root of your SDK.
This directory can be safely deleted.
log directory in the SDK root can be deleted unless you want
to preserve the old logs.
In the 2.4.0 SDK the logs have moved to
deps.properties file may contain old properties.
You should remove all properties in that file that you did not add yourself.
Upgrading deployment module configuration
At this point all of the SDK infrastructure has been upgraded so that tools run from now on will use their upgraded versions, and only the deployment module is left to be upgraded. This is potentially the most involved step, depending on the extent of customization of the current module. You will need to be able to re-apply the changes you made to the current deployment module to a new one created with the upgraded SDK.
If the only configuration you have done of the deployment module outside of adding dependencies on custom modules was with the installer then upgrading will be easy. In such a case you can simply move the deployment module out of the way, create a new deployment module with the installer, and re-add your custom dependencies as explained in Adding the feature to the deployment module.
If you have made changes to the deployment module beyond those made by the
installer then you will have to manually re-apply them to the new deployment
This will be easiest if your SDK is under version control and you can do a
diff between a revision with a pristine (or only installer-configured)
deployment module and one with the changes since then.
Otherwise you should switch to your SDK backup, move the current deployment
module out of the way, recreate it, and then use the
diff program to
determine the changes between the recreated one and the configured one.
Once you have created a diff using one of these two methods use either the
installer or the
sdkadm tool to create a new deployment module and then
apply the changes from the diff in whatever way works best for them.
Don’t forget to re-add your custom dependencies to the new deployment module as mentioned above.
Your SDK should now be fully upgraded and can be used to deploy a new Sentinel installation.