Overview

The platform is under continuous development process, with each release adding new features, improvements and bug fixes. Generally it is just enough to merge all the changes from latest release to get your system up and running. However from time to time there are features that require schema changes, updating default system attributes values and actions to make your data (e.g. image in image vault, password generation algorithms) comply with the latest changes in code.

All information to migrate from one version to another is kept in: YC_HOME/env/migration

This directory contains a number of sub directories with detailed instructions and important notes in order to migrate from one version to another. If you are jumping versions say from 2.2.0 right to 3.1.0, you must do all steps in sequential order. i.e. 2.2.0-3.0.0, then 3.0.0-3.0.1, then 3.0.1-3.1.0.

Each migration sub directory contains:

• sql/schema-changes.sql file that contains example SQL statements for MySQL and Derby RMDBs (Derby version of SQL is commented out). Note that these are MySQL specific statements. We do not provide automated DB upgrades since this is too risky for production systems, nor we have any knowledge of the customisation that could be specific to your variant of YC. The upgrade process should be fully controlled by developers performing it and they should provide specific instructions relevant to your production environment (See YC-513 for more details).
• a number of *-README.txt files that have detailed instructions on specific features (e.g. YC-542-README.txt). You can use our public jira to find more information on the task. However "readme" files should contain enough information to describe necessary actions for the upgrade.