This page is work in progress while we're conducting the current release and updating the old ToDo list for the new release process.

It's Release Time!

So it's time for a release again, is it? Well, you're in for quite a bit of work to ensure everything's in order. But fear not – this handy guide will help you find your way through the daunting but important pile of steps you'll have to wade through on your way to releasing the next version of KIELER. So, as usual, go and help yourself to a nice cup of tea or coffee and start...

Almighty Release ToDo List

Follow this list and be rewarded by a smoothly running release process.

  1. Increase the version numbers of all plugins that have been part of the previous release in their MANIFEST.MF and pom.xml files. To that end, take a look at the changes performed on each one of them since then. For the moment, we'll leave the major version number (the first number) alone. If there have been breaking API changes (a method added to a public interface, changed public method signatures, removed public methods, that sort of thing), you will want to increase the minor version number (the second number). If there were any changes that didn't break the API, increase the revision number (the third number). There is one other case for changing the minor version number: if an important dependency has changed. For instance, regenerating Xtend-based code with a new version of Xtend will justify increasing the minor version number. If the dependency only concerns a KIELER component, however, increasing the revision number will suffice. In such cases, we just assume that users will update the plugin on which we depend anyway.
    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.
  2. Increase the version numbers of all features in their feature.xml and pom.xml files. The concrete part of the version number to be increased depends on the version number increases of plug-ins included in the feature.
  3. Set the version numbers of all source features to the version number of their counterparts in their feature.xml and pom.xml files. You might easily forget that since we don't have working Eclipse projects for our source features at the moment. You will have to manually navigate to the source features and change their version numbers from outside Eclipse.
  4. Update the feature version numbers in the product files. We currently have two product files that depend on specific versions of our features: kieler.product (part of the core.product plugin) and kwebs.product (part of the kwebs.server plugin). Open both inside Eclipse and update the version numbers of the features they include. Once you're finished, the product files have to be made available to the build system. Copy kieler.product to build/de.cau.cs.kieler.repository and copy kwebs.product to build/de.cau.cs.kieler.kwebs.repository.
  5. Update the feature version numbers in the update site repositories. The features are referenced from the category.xml files in the KIELER and KWebS update site folders (build/de.cau.cs.kieler.repository and build/de.cau.cs.kwebs.repository, respectively).
  6. Update the feature list in the SDK feature. Make sure that the list of features to be included in the SDK feature is still up to date.
  7. Update plugin dependencies to match the respective requirements. Dependencies to KIELER plugins should specify no version number. Dependencies to other plugins should be updated if any compatibility problems are known (e.g., API changes between versions). Update feature dependencies to other features and plugins according to the plugin dependencies.
    This point is actually not realistic since doing this right would require so much work that we wouldn't be able to do anything else. It has to be decided at some point what to do about this.