Versioning

Introduction

One of the topics that the original GitFlow article 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 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.