Versioning Feature and Release Branches

For some time I was thinking how to solve a use case where we track both feature and release branches in Reliza Hub.

The problem encountered is related to versioning. Here is the problem in a nutshell: if all branches share same versioning schema, then releases overlap and by simply looking at versions we don’t know which is which. If we only deal with release branches, the solution would be what I presented earlier in this blog – namely, separating branch versions by Minor in SemVer case or by Month in the CalVer case.

However, feature branches complicate this – there are just too many of them to do Minor separation. These days a frequently used pattern is to create a feature branch per each task ticket or per each pull request, and then merge it into master (or in case of urgent fixes – also into release branch). Conventional naming for feature branches would be just the ticket name it references, i.e. TICKET-134 or PR-12. So, we end up having lots of such feature branches with unclear versioning.

The way we started to solve it with Reliza products is by adding specific versioning component Branch. So that our default versioning schema for feature branches becomes Branch.Micro. A sample release version for our feature branch could be TICKET-134.5 – meaning 6th release of our TICKET-134 branch.

There are of course variants, where you could do something like YYYY.0M.Branch.Micro – this way you can also track creation month of the branch. The main benefit of such approach is that feature branch releases do not mix with release branch releases, so we wouldn’t accidentally pull them into non-test environments.

Finally, we are going to introduce approvals for release branches. So that we explicitly indicate which feature branch should be used per environment.

The resulting release selection structure on Reliza Hub is going to look as following:

  1. Identify to what environment our instance belongs
  2. Identify project branch that is currently approved to this environment
  3. Identify most recent release from this branch approved to this environment -> this would be the release version that would be returned to UI and integrated CD system.

This internally creates 2-step selection process instead of 1-step process we used previously. That 1-step process required clients to explicitly specify desired branch, which was not obvious in many cases (as shown above). 2-step selection would add greater logic complexity onto Reliza Hub but remove complexity from the clients – who would just ask for latest approved release per environment and get it. Without worrying about branches.

We are currently actively working on implementing the above logic and it hopefully should be live by the end of June 2020. Meanwhile, I would appreciate any comments or feedback via DM to my LinkedIn.