Skip to content

Release Creation

Jump to bottom
DaGeRe edited this page Nov 9, 2024 · 7 revisions

Prerequisites

In the remaining document the version number is represented by $VERSION and the previous version with $PREVIOUS.

Preparation

1. Prepare unit tests

Check if the generated unit tests are available for all records of previous release. This task is normally done at the end of a release and integrated into the master branch.

  • If this is not the case
    • Check out previous release branch $PREVIOUS
    • Run Eclipse function to scan record API and generate test classes
    • Run tests
    • On errors determine cause and create tickets
    • Commit and push changes, and merge them in the current master
    • Switch to master HEAD
  • Run tests
  • If errors occur trigger tickets to fix those issues. Only on success proceed.

2. Initialize release branch

  • Fetch everything from the remote repository: git fetch
  • Checkout stable: git checkout stable
  • Ensure that the stable branch is up to date: git rebase origin/stable
  • Create a branch for the release: git checkout -b $VERSION-RC
  • Set the final release version number
    • In the gradle.properties file: kiekerVersion = $VERSION
    • In bin/dev/assemble-tools.sh (and the other shell files in the same folder)
  • Manually modify the following files: CITATION.cff, codemeta.json
  • Update the copyright year tags in the source files by
    • Adjusting the year in the updateLicenseHeaderYear task
    • ./gradlew updateLicenseHeaderYear
  • Modify the HISTORY file
  • Execute a build to update version strings etc.: ./gradlew clean distribute -x check -x test
  • Commit the changes
  • Push the branch: git push -u origin $VERSION

3. Download all release files

Save the files downloaded from the Jenkins job. An all-in-one zip can be obtained from https://build.se.informatik.uni-kiel.de/jenkins/job/kieker-monitoring/job/kieker/job/<version>/lastSuccessfulBuild/artifact/*zip*/archive.zip
Copy HISTORY to root dir as README unzip kieker-1.11-binaries.zip && cp kieker-*/HISTORY README && rm -rf kieker-1.11/
Compute MD5 sums for all files
    Linux: md5sum * > md5sums.txt
    Mac md5 * > md5sums.txt
Compare MD5 sums with the files on Jenkins!

4. Publish release files on GitHub

  • Create a release
  • Select to create a new tag and select the branch
  • Release name is "Kieker "
  • Upload files: HISTORY, binaries, javadoc, README.md

5. Upload to Maven repository

  • The artifacts should be uploaded to Sonatype in the staging area (check whether the last Jenkins job was successful)
  • Login to https://oss.sonatype.org/index.html#stagingRepositories (with Sonatype JIRA credentials)
  • Go to the staging repositories and check whether everything is alright (the process can still be stopped here; if you release it, that irreversible)
  • Close the repository, wait for a few minutes, and afterwards release the repository

6. Announce Release

Update web site (Sometimes easiest to search/replace in a separate editor):
    http://kieker-monitoring.net/download/
    http://kieker-monitoring.net/download/nightly/
    http://kieker-monitoring.net/release-notes/ (copy contents from GitHub releases page because the formatting is correctly transferred)
    http://kieker-monitoring.net/documentation/
    Jira
        Close Release
        Create version(s) and date(s) for new release(s)
    Update Kieker calendar (if new release dates added)
    http://kieker-monitoring.net/documentation/quickstart-guide/ (+ Eclipse version)
Create post on Twittter
Create news post on  Kieker web site. Template:

Title: Kieker <VERSION> released
Body:  
On October 1, 2015, we released version 1.12 of our Kieker framework for application performance monitoring and dynamic software analysis. As usual, the release is available for download at http://kieker-monitoring.net/download/.

PASTE HISTORY FILE

For details and download see http://kieker-monitoring.net/

Send mail to users and develops list (template above)

Send release to SPEC RG release manager for publication at  http://research.spec.org/tools.html

8. Post Release

  • Create a tag for $VERSION (for instance, git tag $VERSION && git push origin $VERSION)
  • Create a branch from the release branch to merge the changes back to main: git checkout -b $VERSION-back-to-main
  • Update version number in the gradle.properties file (remember to include -SNAPSHOT!)
  • Execute ./gradlew clean build -x check -x test to update version strings
  • Update version number in the Eclipse settings (@since tag) .settings/org.eclipse.jdt.ui.prefs
  • Commit the changes and push
  • git commit -am "merging release branch back to main"
  • git push origin $VERSION-back-to-main
  • Create a pull request on GitHub to the main branch
  • Wait for the checks of the pull request to be successful
  • Delete local and remote branch $VERSION
       git branch -d 1.9
       git push origin --delete 1.9

9. Initial Actions for Next Version

  • Create ticket to remove artifacts marked with @deprecated (to be removed in X.YZ) iff the next release is a major release
Clone this wiki locally