What is a release in software development ?

The release is the process used to validate a given set of code changes are ready to be deployed/used. This process includes:

• version management
• change management
• software configuration adjustment
• software integration ( if not done continuously )

Semantic Versioning (SemVer)

Semantic versioning specification defines a version format for the software artifacts to easy the process of communicating what type of changes were introduced in given version. The version formats are:

Version type	Version syntax
Core Version	X.Y.Z
Pre Release Version	X.Y.Z - {{pre-release}}
Pre Release Version with build	X.Y.Z - {{pre-release}} + {{build}}

The core version (X.Y.Z) of an artifact in semver is a result of 3 versions separated by a dot:

• X is the major version
• Y is the minor version
• Z is the patch version

A Pre Release version is always before a Core Release Version !

The Major Version (X)

A increase in the X version ( 1.0.0 → 2.0.0 ) mean changes were done to the software artifact that are not backward compatible with the previous versions. As an example removing functionalities of a public interface/api require a major version update.

The Minor Version (Y)

An increase in the Y version (1.0.0 → 1.1.0) mean changes introduced are backward compatible with previous. Minor version is to increase when deprecating a public interface/api, adding a new functionalities that do not break existing public interface/api.

The Patch Version (Z)

An increase in the patch version Z (1.1.5 → 1.1.6) means bugfixes, security patches, performance optimizations or dependencies updates (that do not require internal code refactoring on the software component) were introduced in the software solution and backward compatible.

Pre Release Version

Pre release version exist to denote an unstable package is produced either because it is not fully develop, or under code review or even under quality assurance process before being able to be released. Pre release versions can help multiple repository software architectures on cross repository feature development as well as software products that are comprised of several software components that need to be verified together in a quality assurance phase before be qualified to a release.

Example of pre-releases syntaxes:

Version Syntax	Examples
X.Y.Z - mr.{{mr_number}}.{{short_commit_sha}}.{{date}}	1.0.0 - mr.177.470bcf4.170320252030
X.Y.Z - rc.{{release_candidate_number}}	1.0.0 - rc.1; 2.1.7 - rc.7
X.Y.Z - {{branch}}.{{short_commit_sha}}.{{date}}	1.0.0 - main.177.470bcf4.170320252030

Changelog

Changelog is a technical detailed record of what happened to each software component in each release. Changelog is used by developers to keep track of changes in components they depend on. If a software application is comprised of several components each one will have its own changelog, when the components are released independently. A Changelog have several sections to aggregation information as follow:

1. New Features
2. Enhancements
3. bugfixes
4. Removed
5. Deprecated
6. Security

Release Notes

Release notes are a non technical documentation the end user can read to understand the impact a given release had on the software product. Release notes can be system specific ( e.g.: windows, linux, android, macOS, ARM, etc) and can educate non technical users on topic such as :

• new user stories implemented
• new integrations added
• UI updates/changes
• new requirements to run the application

Release process with a release branch

A release starts by branching from develop in a commit that contains all the changes to be included in a given release, the release branch name follows the syntax release/vX.Y.Z . Each commit in release/vX.Y.Z will generate a release candidate vX.Y.Z-rc.<release_candidate_number>.

• Each release candidate is:
  • fully verified by the CI pipeline
  • runs all types of integration tests available ( e2e, smoke tests)
  • deployed in QA env to be verified by the QA team with manual tests
• New commits can be added to release/vX.Y.Z to:
  • Address any type of bugfixes
  • Solve performance issues
• When a release candidate version passes all the verification stages ( automatic and manual ) that RC version is label as the final RC version ✅ and:
  1. release/vX.Y.Z branch is merged back to develop and main
  2. release/vX.Y.Z branch is deleted !
• Onmain branch after the merge of release/vX.Y.Z :
  1. A git tag is generated with value vX.Y.Z
  2. The Changelog from the previous tag to the new vX.Y.Z tag is generated
  3. A Release is created attached to the tag vX.Y.Z with the generated Changelog file

Each feature branch merge to develop branch will generate a pre-release version, because it was not fully validated. Perhaps unit tests were verified, but there could be some important manual steps that were not checked or will need to be re-checked when another feature is merged to be able start a new release. The release branch is then created so a given released version is fully verified in a point in time when a set of changes are of interest to be released.

Release process directly from mainbranch

For all software components that can be fully and automatically verified for any code changes, but the users want to control the release timing.

The user can trigger a release from main whenever the bulk of changes introduced in main is suited for it and or the release time period has been hit. The release core version can be calculated from the commits introduced from the last release or be expressed by the used. In the first case conventual commits specification could be a great ally to standardize release version bumps rules.

Release process in continuous delivery

For all software components that can be fully and automatically verified for any code changes, the release process can be continuous and support a continuous delivery pipeline.

main branch contains code that is released and fully ready to be deployed to production.

• Any code change just needs to branch from main . For example to create e feature branch
• development is done on the feature branch, every commit is fully verified by the CI
• the feature branch is regularly updated with the new content of main
• Onmain branch after the merge of feature branch the following actions happen automatically:
  1. release version for merge commit is decided based on the changes introduced
  2. merge commit is tagged with the release version, for example : x.y.(z+2)
  3. a release is created attached to the tag x.y.(z+2) , the released artifacts are labeled with that version and the Changelog is published with the changes introduced in this latest version.
  4. finally the released artifacts are deployed to production.