Reputation: 573
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:
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
Upvotes: 2
Views: 1621
Reputation: 8353
As you describe I see these versions:
1.2.1
Current version in Master is 1.2.11.3.0-alpha+branch2
User creates branch (Branch2) to implement some new functionality1.3.0-beta+branch2
User deploys Branch2 into QA for review and sign-off1.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.
Upvotes: 2