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 is a very simple scheme built around the X.Y.Z-buildNo concept (for example 2.6.0-2 or 2.6.0-SNAPSHOT20120501):
- 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-SNAPSHOT201205012).
- 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).
- When you create a new branch, you need to manually update the software’s version number. The HubFlow tools cannot do this for you.
- If you’re using RPM, you need to put the buildNo part of the version number into the release tag in your spec file (or add a release tag to the configuration section if you’re using Maven’s RPM plugin).
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.