Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. Set version numbers.The pragmatics plugins and features share a common version number corresponding to the current release. All plugins should have the version number of one minor version higher than the previous release (see Semantic Versioning)
    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 pragmatics repository:

    Code Block
    languagebash
    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.

    Note

    There are some external bundles and features in the pragmatics repository not in the schema de.cau.cs.kieler.* that are built and hosted with a pragmatics release. Their version should stay the same as where it came from. The script does not update those fixed versions, except for the build/de.cau.cs.kieler.pragmatics.repository/category.xml file. Correct the version number manually there or correct the script to exclude that file and remove this note.

  2. Check if all plug-ins to be released are contained in a feature. This is particularly important for new plug-ins.

  3. 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. The branch should follow this release-branch naming scheme:

    Code Block
    releases/pragmatics-YYYY-MM[-##]

    The optional -## in the end is an additional consecutive number for multiple releases in the same month.

  4. Increase the version numbers on the master branch. After the release the master should have the version of the next release. This is important as it makes the nightly build on the master branch to be a snapshot for the next release and usually accelerates step 1 of the next release.
  5. Configure the build files in the repository.  The build instruction in the repository must be configured for the release build. To apply the configuration do the same thing as in this commit on the release branch. Make sure to update all associate sites to their release that you want to depend on.

  6. Test the Maven build locally. Execute the maven build locally to ensure your release-branch can build successfully to avoid needing to commit multiple 'build fixed'-commits until the branch is ready.
  7. Tell Bamboo to build the release. Configure the build plan Pragmatics Updatesite Release YYYY-MM of the last release to build the new one. Change the following settings:

    • KIELER Pragmatics Release Repository (to the new corresponding release branch)
    • pragmaticsReleaseVersion Variable
    • Plan name
  8. 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.
  9. 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!
  10. 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.
  11. Create a tag of the release.
  12. Publish release nodes and update download links in:
  13. Close the Jira version, set the new default version, and add a new version.
  14. Create a new Stream for the release in the Oomph setup.
  15. Send the word out to the mailing list and do a release party!