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.

  • Determine version number for the new release.
  • Have the Eclipse API scan utility present in your Eclipse IDE
    • Available in [email protected]:kieker/utility.git
    • Import project de.cau.cs.se.kieker.record.analyser
    • Build the project
    • Start an Eclipse instance with the analyser
    • Import the Kieker projects
    • Note that you can also export the project and install it in your normal Eclipse installation.

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

4.1 Sourceforge [?deprecated?]

https://sourceforge.net/apps/trac/sourceforge/wiki/Release%20files%20for%20download#Createoreditarelease

Easiest way: Via scp (command line or ui like filezilla)

scp file.zip [email protected]:/home/frs/project/kieker

Alternatively: Uploads via the File browser.
    /
        kieker-<version>_binaries.zip|tar.gz
        kieker-<version>_sources.zip|tar.gz
        kieker-userguide.pdf (e.g., extracted from zip)
        README (copy of HISTORY)
    /javadoc/
        kieker-<version>-javadoc.jar
    Check MD5 sums! (takes a while to become available on SF)
    Set kieker-<version>_binaries.zip as default artifact for all platforms

4.2 GitHub

Create a release
Select to create a new tag and select the branch
Release name is "Kieker <version>"
Upload files:

[Development > Release Creation > image2022-3-18_22-32-55.png]

4.3 Web site (API)

Publish API (Javadoc) in https://github.com/kieker-monitoring/api

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)
    Upload user guide to  http://eprints.uni-kiel.de/16537/ and move to top position in list (arrows)
    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