HAMPEL SOFTWARE ENGINEERING

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== 04 Release Management ======

> //Release Management is the process of managing software releases throughout an ongoing cycle of development, testing, and release.//


<WRAP center round help 99%>
HSE internal documentation: \\
[[organization:internal-kb:sw-dev:release-process|Processes: Manual Steps]]
</WRAP>


===== 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/<customer>/<project>/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''.