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...
Follow this list and be rewarded by a smoothly running release process.
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. Also, you may want to write down for every plugin which part of its version number was incremented – that will make the next step way easier. |
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.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, if one of them is to be released. Also, update the version numbers of the products themselves and don't forget to synchronize the changes (there's a button on the Overview page of the product configuration editor). 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
. If the contents of the product icon folders have changed, these changes have to be made available to the build system as well by copying them appropriately.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). Take this opportunity to also adapt the update site category names to include the proper version number of the new release.feature.xml
file and is best done through mass search & replace. Also, the repository build folders (for instance, build/de.cau.cs.kieler.pragmatics.repository
) generate an index.html
file for the update sites they are generating. Change the update site metadata in the corresponding pom.xml
by updating the update site version and the update site description (released update sites should have "Release" as their description, nightly build update sites should have "Nightly Build" as their description). Also update the update site version in the master branch.compositeArtifacts.xml
and compositeContent.xml
. These two files are in /home/kieler/public_html/updatesite
./home/kieler/public_html/files
. Take care to rename the files appropriately: the nightly build files don't include version information, but only a timestamp.