Upgrading an SDK project

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 created an install.properties file. Make sure this file is present in the current SDK in that case to simplify configuring the new deployment module.

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.

The build infrastructure consists of the build directory and the build.xml file in the SDK root directory. Replace both of these with the versions from the new SDK.

The 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 outright. However, depending on your situation the process should still be relatively straightforward.

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 branch.name property.

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:

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:

The release.properties and 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. Similarly, the 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 build/target/log.

The deps.properties file may contain old properties. You should remove all properties in that file that you did not add yourself.

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 module. 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.