When to increment a version number in the Release management cycle

Question

We use a combination of GitHub, TeamCity, CodeReviews, Octopus deploy to manage our overall Release Management process. We develop websites, and several internally used API's.

We're looking to implement better versioning of our API's in-particular and will use Semver.

My question is, at which stage do you assign a version number to it?

Example:

Current version in Master is 1.2.1
User creates branch (Branch2) to implement some new functionality
User deploys Branch2 into QA for review and sign-off
User merges Branch2 into Master and Releases to Production.

At what stage should the version have been incremented to 1.3.0? If it is updated at the stage when it goes into QA, it is possible that another developer in the meantime creates another feature branch which is tested and ready for Release into Production much quicker than Branch2 was - so really the later should have been 1.3.0 whereas Branch2 which will be pushed out to Production weeks later should have [possibly been 1.4.0.

So, am i right in thinking that the version number should only be incremented once QA has been signed off, and prior to the final merge back into the Master branch?

Thanks for your time in advance Regards, dotdev

Yes, the version number will be the binaries - i.e. The version number will be set in the Properites file. — dotdev
– dotdev, Commented Nov 30, 2016 at 0:11

Giulio Vian · Accepted Answer · 2016-11-30 09:05:14Z

2

As you describe I see these versions:

1.2.1 Current version in Master is 1.2.1
1.3.0-alpha+branch2 User creates branch (Branch2) to implement some new functionality
1.3.0-beta+branch2 User deploys Branch2 into QA for review and sign-off
1.3.0 User merges Branch2 into Master and Releases to Production.

Increment to the next version must be done immediately after any official/production release. Here is a sketch that could help.

feature                           *-(1.3.0-beta+feature1)---*                            *-(1.4.0-beta+feature2)--
                                 /                           \                          /
 master  -[v1.2.1]-(1.3.0-beta)-*-----------------------------*-[v1.3.0]-(1.4.0-beta)--*-----
           \                                                     \      
release     *----                                                 *---

You manually apply tags to official releases represented by square brackets, while the version (normal parenthesis) takes in account tags in history.

I suggest to take a look at the wonderful GitVersion tool to help you in managing the calculation.

answered Nov 30, 2016 at 9:05

Giulio Vian

8,3632 gold badges36 silver badges43 bronze badges

Sign up to request clarification or add additional context in comments.

2 Comments

dotdev Over a year ago

That's interesting....I'll need to check that TeamCity, Nuget and Octopus all support non numerical release numbers i.e. 1.3.0-beta0009. Any thoughts?

Giulio Vian Over a year ago

For sure it would be nice if they do, but the only important thing is that you can easily correlate the data. E.g. says tool X produce identifiers like 'Rel2016-11-30T12.42', you can save the version control information in a relnotes.txt file or to name the packages or to add a tag/label associated with the object (e.g. a release pipeline) in the tool. And (I often do) the other way round so build identifier is appended to the version number in the binaries (I use free-text version field like AssemblyInformationalVersionAttribute).

Collectives™ on Stack Overflow

When to increment a version number in the Release management cycle

1 Answer 1

2 Comments

Your Answer

Hot Network Questions

Collectives™ on Stack Overflow

1 Answer 1

2 Comments

Your Answer

Sign up or log in

Post as a guest

Related