====== 04 Release Management ======
> //Release Management is the process of managing software releases throughout an ongoing cycle of development, testing, and release.//
HSE internal documentation: \\
[[organization:internal-kb:sw-dev:release-process|Processes: Manual Steps]]
===== Introduction =====
Whenever we finish a set of features, enhancements or bug fixes in one of our products or projects, we conduct various methods and levels of testing. If the software is verified to be in a stable and functional state, it is //released// to the customer or to the public.
Each release gets a unique and "human-readable" identifier, a //[[#version_numbers|version number]]//. Some of these releases are distributed by copying an archive file of the software to our web server and providing download links.
We have defined and documented our own, personalised [[kb:bestpractices:wow:releases|process for releasing software]]. You can find details about that on our [[kb:bestpractices:wow|Way of Working]] pages. Many of our projects are released automatically through our [[https://rat.hampel-soft.com|Release Automation Tools]].
===== Accessing releases with Dokuwiki =====
In order to keep things simple for you, we have developed a [[https://code.hampel-soft.com/open-source/dokuwiki-gitlabapi|Dokuwiki plugin]] that serves as a simplified front-end to GitLab and our file servers, displaying a list of releases and allowing to download associated files directly within your Dokuwiki project page.
For your project, wou will find the list of software releases as a subpage of your project page:
/projects///releases
=== List of releases ===
|{{:processes:gitlabtags.png?direct&600|}}|
|List of releases|
For each release, the list displays
* the release name (also called //version number// or //tag//)
* the first 8 digits of the git commit hash
* the user and email of the comitter
* the date this version was committed
* the commit message
* associated downloads (if any)
----
===== Version Numbers =====
==== Format ====
We loosely adhere to the [[http://semver.org|Semantic Versioning]] standard. This means that a normal version number takes the form ''X.Y.Z'' where ''X'', ''Y'', and ''Z'' are non-negative integers:
* ''X'': Major version - identifies versions that introduce //incompatible API changes//
* ''Y'': Minor version - gets increased when //functionality// is added in a //backwards-compatible// manner
* ''Z'': Patch version - shows versions with //backwards-compatible bug fixes//
Elements increase numerically. For instance: ''1.9.0'' -> ''1.10.0'' -> ''1.11.0''.