Content Comparison

...

1. Manually inspect contents. Unfortunately, it's hard to give guidelines here. One goal is to look for contents (files, directories) that do not belong into the archive (e.g., tmp folders,).
2. Test tools --- Linux & Windows
3. Execute user guide examples:
   • ch2--bookstore-application

     ./gradlew run
     

   • ch2--manual-instrumentation

     ./gradlew runMonitoring
     ./gradlew runAnalysis -Danalysis.directory=<DIR>
     

   • ch3-4--custom-components

     ./gradlew runMonitoringAndAnalysis
     

   • ch5--trace-monitoring-aspectj

     ./gradlew runExampleOperationExecution
     ./gradlew runExampleFlowEvents
     

   • appendix-JMS -- see instructions in user guide appendix
   • appendix-AMQP -- see instructions in user guide appendix
   • appendix-Sigar -- see instructions in user guide appendix
   • JavaEEServletContainerExample -- see instructions in user guide appendix
   • Demo (also included in JavaEEServletContainerExample)
4. Execute the other examples

...

• Prepare artifacts
  • Create kieker-<version>.pom, e.g., from SNAPSHOT upload (change version nameslocal repo, e.g., ~/.m2/repository/net/kieker-monitoring/kieker/1.15/kieker-1.15.pom
  • Sign files with gpg -u 8E97E26A -ab <file>
  • Resulting set of files:

    • kieker-1.13-aspectj.jar kieker-1.13-emf.jar kieker-1.13.jar kieker-1.13-javadoc.jar kieker-1.13.pom kieker-1.13-sources.jar
      kieker-1.13-aspectj.jar.asc kieker-1.13-emf.jar.asc kieker-1.13.jar.asc kieker-1.13-javadoc.jar.asc kieker-1.13.pom.asc kieker-1.13-sources.jar.asc

• Publish release in Staging Repository (see also  8a. Release It (Sonatype User Guide) )
  • Login to  https://oss.sonatype.org/index.html#stagingRepositories (with  Sonatype JIRA credentials)
  • Select Staging upload → Artifact(s) with POM
  • Upload the files from above including the .asc files (note that Sonatype does not ask for it here but will complain later in the staging repository)
  • Select Staging repositories and filter by netkieker and you should see the repository with status open (last time, it was closed already)
  • Inspect the files.
  • If everything's fine, trigger the "Release" operation. Note that this step is irreversible (i.e., a file once published at Maven Central cannot be replaced)!

...

1. Update web site (Sometimes easiest to search/replace in a separate editor):
   
   1. http://kieker-monitoring.net/download/
   2. http://kieker-monitoring.net/download/nightly/
   3. http://kieker-monitoring.net/release-notes/ (copy contents from GitHub releases page because the formatting is correctly transferred)
   4. Upload user guide to  http://eprints.uni-kiel.de/16537/ and move to top position in list (arrows)
   5. http://kieker-monitoring.net/documentation/
   6. Jira
      1. Close Release
      2. Create version(s) and date(s) for new release(s)
   7. Update Kieker calendar (if new release dates added)
   8. http://kieker-monitoring.net/documentation/quickstart-guide/ (+ Eclipse version)
2. Create post on Twittter
3. 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/
   

4. Send mail to users and develops list (template above)

...

1. Create a tag for 1.13 (for instance, with gitg)
2. Create a branch from the release branch to merge the changes back to master
   (1.13)*$ git checkout -b 1.13-back-to-master
3. Update version number in the gradle.properties file (remember to include -SNAPSHOT!)
4. Execute $ ./gradlew clean distribute build -x check -x test to update version strings
5. Update version number in the Eclipse settings (@since tag) .settings/org.eclipse.jdt.ui.prefs
6. Commit the changes and push
   $ git commit -am "merging release branch back to master"
   $ git push origin 1.13-back-to-master
7. Create a pull request on GitHub to the master branch
8. Wait for the checks of the pull request to be successful
9. Delete local and remote branch 1.9

      git branch -d 1.9
      git push origin --delete 1.9
   

10. Push tag git push origin 1.9
11. Update version numbers on http://kieker-monitoring.net/download/nightly/
12. Update version number in https://build.se.informatik.uni-kiel.de/jenkins/job/kieker-nightly-benchmark/configure
13. Run Eclipse function to scan record API and generate test classes
    1. The tool is available in gitlab@build.se.informatik.uni-kiel.de:kieker/utility.git
    2. import de.cau.cs.se.kieker.record.analyser
14. Run tests
15. On errors determine cause and create tickets

...