> For the complete documentation index, see [llms.txt](https://xmlking.gitbook.io/micro-apps/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://xmlking.gitbook.io/micro-apps/concepts/versioning.md).

# Versioning

## Introduction

One of the topics that the [original GitFlow article](https://nvie.com/posts/a-successful-git-branching-model/) doesn’t address at all is what scheme to adopt for your software’s version numbers.

But we believe that life is easier for **everyone** if version numbers **mean the same thing** to everyone who is working on a piece of software.

## Semantic Versioning

[Semantic versioning](http://semver.org) is a very simple scheme built around the **X.Y.Z-buildNo** concept (for example **2.6.0-2** or **2.6.0-SNAPSHOT**):

* Increment **Z** when you fix something
* Increment **Y** when you add a new feature
* Increment **X** when you break backwards-compatibility or add major features
* Use the **buildNo** to differentiate different builds off the same branch, and to differentiate between development, test and production builds.

## Version Numbers And GitFlow Branches

Here's what to build from which branch.

* **Feature branches** and the **develop branch** should always build **snapshot** versions (e.g. 2.6.0-SNAPSHOT).
* **Release branches** and **hotfix branches** should always build **release candidate** versions (e.g. 2.6.0-0.rc1).
* The **master branch** should always build unqualified versions - versions without build numbers (e.g. 2.6.0).

Please remember:

**Remember:**

* When you create a new branch, you need to **manually update** the software's version number.  The **GitFlow tools** cannot do this for you.

## What You Should Install Where

*As a rule of thumb ...*

* **Snapshot versions** should only be installed on **dev boxes** and **integration environments**.  They shouldn't be deployed to any of the **dedicated test environments**.
* **Release candidates** should be installed in the **dedicated test environments**.  In an emergency, a release candidate can be installed into the **production environment**.
* **Production releases** can be installed anywhere - and they are the only kind of build that should be installed into the **production environment**.