# 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.

Often, we think of software releases as iterations towards a "major" release, or a release that is stable enough, with adequate features, that it could be given to a user for production use. Often we'll characterize releases based on how close they are to that target.

From launchdarkly.com:

• Pre-alpha: This stage encompasses all activities that lead up to a major release, including gathering requirements, deciding on the pricing for new features, design, and development.
• Alpha: This is usually where testing and validation of the new code’s behavior begins. Alpha releases are typically tested within the company.
• Beta: Once software passes alpha, it enters the beta stage. Some companies share the beta with prospects and customers as a demo, or make it available for beta testing by a group of users who opt in. This can be a good way to engage your power users or people interested in early access to new features.
• Release candidate/s: Once any bugs surfaced in beta testing have been addressed, a release candidate is ready to undergo evaluation for stability and suitability as the final version of the software to be released.
• Final release: If no significant bugs emerge when testing the release candidate, you’re ready to release the final version. When and how you do that will depend on your methodology and deployment and release strategies (we’ll dig into those below).

# Purpose

This should be a well-defined process that does the following:

• Completes documentation and source code changes,
• Adequately captures the state of the project at the time of the software release, such that you could describe precisely what functionality it contained at a later date (or more cynically, if a particular bug was fixed in a particular release).
• Generates artifacts, including release notes, installer images and project documentation.

# Steps

Here's what you should do each release.

1. 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.
2. Assign a version number. In your build.gradle.kts, you should change the VERSION to the next valid product version number.

3. 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, and (c) build your code and generate installers from your Gradle projects.

4. Write release notes.

Each software release should be documented in a Wiki page, named according to the sprint number e.g., Sprint 1 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., 0.1.0, or 1.0.0 for your first sprint.
• A bullet list of the major changes that were included in the release, and a link to the issues list in GitLab.

5. 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 the images created to the wiki page, so that user can locate them in the wiki and install them directly.