Skip to content

Latest commit

 

History

History
59 lines (41 loc) · 3.72 KB

RELEASE.md

File metadata and controls

59 lines (41 loc) · 3.72 KB
Raw

Creating a Release

Release workflow

As release workflow we use the Gitflow Workflow (see https://www.atlassian.com/git/tutorials/comparing-workflows#gitflow-workflow).

For releasing a new version of this project, we integrated the jgitflow-maven-plugin (see https://bitbucket.org/atlassian/jgit-flow/wiki/Home).

Steps to build a new version:

  1. Checkout branch development.

  2. Run mvn install -Pwith-app.

  3. If the build was successful, run mvn jgitflow:release-start jgitflow:release-finish -Pwith-app,with-dep-poms.

    • You will be asked for the release version. Leave this empty to keep the current snapshot version as release version number (-SNAPSHOT will be cut of by jgitflow-maven-plugin).
    • You will be asked for the next development version. Leave this empty and the plugin will increment the micro release number (1.0.1-SNAPSHOT becomes 1.0.2-SNAPSHOT). If you want to alter the version just type e.g. 1.1.0-SNAPSHOT.

  4. The result is that the current state of branch development gets merged to branch master (without -SNAPSHOT), tagged as releases/version-1.0.1 and the development version is automatically increased.

Version numbers

Version Numbers = major.minor.micro

For correct generation of android version codes the releases have to be at least minor releases. Micro releases are reserved for hotfixes of a published release.

  • Finish of a release: Increase major or minor number
  • Finish of a hotfix (merged directly back to branch master): Increase micro number

Android Version Code

The versionCode for the Android app is autogenerated by the projects version. The convention for the versionCode aaabbbccd (generated of version aaa.bbb.cc) is:

  • d: one digit for SNAPSHOT (0), Release Candidates (RC1 to RC8 = 1..8) or Final Release (9)
  • cc: two digits for micro releases (with leading zeros)
  • bbb: three digits for minor releases (with leading zeros)
  • aaa: major releases (if a > 0)

Local configuration for jgitflow-maven-plugin

The jgitflow-maven-plugin needs credentials for git, which are configurated as variables in sormas-base/pom.xml. To use it you need to configure this in your .m2/settings.xml (or pass it as arguments when executing the plugin).

    <profiles>
            <profile>
                    <id>github-config</id>
                    <!-- For jgitflow-maven-plugin against github.com -->
                    <properties>
                            <github.sormas.user>myUserName</github.sormas.user>
                            <github.sormas.password>myPassword</github.sormas.password>
                    </properties>
            </profile>
    </profiles>

    <activeProfiles>
            <activeProfile>github-config</activeProfile>
    </activeProfiles>

Perform load testing and upload the results

When a release has been done and the new SORMAS version has been deployed to the server that is used for load testing, refer to the load testing guide to perform them, ideally multiple times with different amounts of users set in the SimulationConfig.scala file (e.g. 1, 20, 100). Navigate to the results folder, rename the folders containing the individual tests (e.g. SIMULATION-NAME_AMOUNT-OF-USERS_SORMAS-VERSION) and zip them. Append the resulting archive to the release on GitHub, as well as a PDF file containing an overview of the results (see an earlier release for an example on how to do this; you'll need to open the individual simulations and retrieve the values from the respective index.html files).