Key

This line was added.

This line was removed.

Formatting was changed.

...

Set version numbers. Since 0.12.0 the semantics plugins and features no longer have individual version numbers. Instead all plugins share the version of the corresponding release.To set the version number in all pom files, manifests of all plugins and features, including their references in other files run the following script located in build/scripts/ in the semantics repository:

Code Block

language

bash

python version.py x.x.x

Info

By the way, this is a good time to make sure that every plugin has a proper license file and proper metadata. Go check the nightly RCA build to make sure that plugin names and provider names are set correctly.

Check if all plug-ins to be released are contained in a feature. This is particularly important for new plug-ins.Your can use the sanity check script to check the feature containment:

Code Block

language

bash

python sanity.py

Update the splash screen with the new version number. Adjust the version number in the splash.svg in plugins/de.cau.cs.kieler.core.product/images. Export to splash.bmp (no alpha channel!) in the plugin root folder.

Expand

title

Info for bmp export

Hints for splash screen adjustments:

Dimensions: 500 x 330 px

If your image program offers a choice, such as GIMP 2.8.10 does, it is important to save the bmp WITHOUT color space information saved or, else, the splash screen will not be displayed on Windows .... apparently a silent failure to read a "modern" BMP file (watch bug 439573). And use care, since in Gimp anyway, the choice is a negative check-off: Do not write color space information is unchecked by default, but must be checked to save the bmp WITHOUT color space information -- just like it says, but as I repeatedly misread.

Also, The bitmap should be saved in 24-bit format (8R, 8G, 8B) for else "funny colors" (such as red instead of blue, or green instead of blue) will sometimes appear if the 32-bit format is used, with 8 bits of "transparency".Taken from: https://wiki.eclipse.org/Platform-releng/Updating_Branding

Create a release branch in the mainline repository. From this point on, the master branch can be used for normal development, while the release branch will only receive bugfixes and release-specific changes. Bugfixes are usually first developed on the master branch, and are then cherry-picked into the release branch.

Increase the version numbers on the master branch. After the release the master should have the version of the next release. Also adjust the splash screen. (Usually accelerates step 1 and 3 of the next release)

Configure the build files in the repository. The build instruction in the repository must be configured for the release build. To apply the configuration run the following script located in build/scripts/:

Code Block

language

bash

python configure.py -release x.x.x

Info

This script is also capable of configuring the repository for a nightly build, to force correct configuration or revert effects of a release cofiguation.

Tell Bamboo to build the release. Configure the build plan of the last release to build the new one. Change the following settings:

Build Repository (corresponding release branch)

semanticsReleaseVersion Variable

Plan name

Publish a few release candidates for testing. Test! One aspect of testing is to assign demo videos to everyone to walk through. Make sure to create tickets for them so that everyone records his findings somewhere.

Proclaim a commit freeze on the release branch. Once all tickets are fixed, no one has any business pushing stuff into the release branch anymore!

Update top-level update site. This is done by adding the new update site URL to compositeArtifacts.xml and compositeContent.xml. These two files are in /home/kieler/public_html/updatesite.