====== 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''.