Creating an RCE release and preparing for the next one is a process that can be split into four distinct steps (or phases):
Trunk preparations - actions that take place in the development trunk before the release branch is split off.
Release candidate building and testing - creation of the release branch, building RCs on the CI server, and applying fixes if necessary.
Final release - creating and publishing the final release build, SCM tagging, posting announcements etc.
Post-release actions - preparing the trunk for the next release.
By convention, the version numbers of all plugins and features are increased in the trunk immediately after a release has been performed. This way, every snapshot build is associated with the upcoming release. For example, all snapshot builds after the 8.1.0 release should be named named "8.2.0.xxx_SNAPSHOT".
The version upgrade process of RCE Core is mostly automated:
Open a shell or command window in "/de.rcenvironment.core/maven/utils/" and run the appropriate "upgrade-core" script for your platform (.bat on Windows, .sh on Linux). Usage:
upgrade-core
{
old core version
}
{
new core version
}
Example: upgrade-core 8.0.0 8.1.0
Due to major structural changes in 8.1.0, the version upgrade script tagged as part of the 8.1.0 release may not be updated to perform the version upgrade to 8.2.0 yet; adapting this script will be one of the first actions after the release.
Build the platform repository and the full product locally to verify that the build setup is consistent; see the "getting started" section on how to do this.
Create a Mantis issue "release x.y.z" for the new version if it does not exist yet (usually, it won't).
Commit the changes under this issue.
Verify the CI/Jenkins build
(Option 1) TODO update this section for 8.1.0+
(Option 2) Keep an eye on the standard periodic builds (nightly, "onCommit", ..) and see if they complete normally. IMPORTANT: This is ONLY appropriate if you are around/available for handling possible problems!
When creating a release that is not based on the current development trunk, the release process is slightly different. Such "maintenance" or "hotfix" releases must always be derived from a stable release.
To create a new release based on a previously-released version:
Create a release branch (similar to a normal release) by copying the SVN release tag folder.
Check out this release branch to your local machine.
As in step 4 of the standard process, upgrade the local version numbers, create a Mantis issue for the release and commit the version changes to it. Note the change in ordering: in a standard release, version numbers are upgraded in the trunk after the release; in a maintenance/hotfix release, they are upgraded before the release, inside the release branch.
Apply and commit the fixes or changes you want in the release; if you want to include specific trunk changes, consider transfering them by using diff patches.
Perform standard step 2 (RC building and testing).
When everything is tested, perform standard step 3 (final release).
If changes were made in the release branch that should also be in the trunk, merge them back selectively . Unlike a normal release, you cannot simply merge all branch changes back to trunk; take special care not to mix up version numbers when merging.