#Software Releases

At the end of each sprint, you should be producing a software release: a releasable version of your project that contains a specific set of changes or functionality. A software release should ALWAYS be well-tested and high-quality, and something that you could give to a user to install and test.

The software release process is meant to do the following:

Finalize documentation and source code changes,
Adequately capture the state of the project at a point-in-time, such that you could describe precisely what functionality it contained at a later date (or more cynically, whether a particular bug was fixed in a particular release).
Generate artifacts, including release notes, installer images and project documentation.

#Steps

Here's what you should do each release.

Consolidate code changes. ALL code changes that you wish to include much be (a) committed, (b) merged back to main, and (c) tested on main.
Assign a version number. In your build.gradle.kts, you should change the VERSION to the next valid product version number.

Semantic versioning is the standard way to assign version numbers based on the type of release. Your version number should follow this. e.g., Version 1.1.0 for your first sprint, Version 1.2.0 for your second and so on.

Generate a release in GitLab (docs). You can start this through Deploy > Release. This will (a) tag your code at this point in time, (b) create an archive of your source code from that tag (note: with proper setup, it's possible to have GitLab build your project installers, but we'll do this step manually below).

See Version control > tags for an explanation of how tags work. Also see the GitLab documentation for more details on working with releases.

Write release notes.

Each software release should be documented in a Wiki page, named according to the release number e.g., Version 1.0.0 Release. You should have a section titled Releases in your README.md with a link to this page (and all previous releases).

The Wiki page for a release needs to include:

The release date, which should be the date that the installer was generated. e.g., 12-May-2023
The version of this release which you increment for each release. e.g., 1.1 for your first sprint, 1.2 for your second sprint and so on.
A bullet list of the major changes that were included in the release, and a link to the issues list in GitLab (either each bullet point links to an issue, or you have a link to the entire list - your choice).

Add installer images

The installer should be a packaged version of your application that a user could use to install your software. If your application consists of multiple components that need to be installed separately (e.g. Android AND desktop) then you need to provide installers for each one.

Acceptable forms of packaging include:

Android: an apk file generated from IntelliJ IDEA or Android Studio that can be side-loaded into a virtual device.
Desktop: an exe, dmg or pkg file that installs the application.
Service: a Docker image that contains your service, with instructions on how to run it (if you are hosting it in the cloud, then you don't need a Docker image).

The last step is to attach these images to your release notes wiki page (Step 4 above), so that user can locate and install them.