Versioning rules
We will use semantic versioning as described here and here.
Right now we will start to work on V1.2.0
as we will have significant changes compared to V1.1.15
: new statistics DB, new folder structure. If we will need to make patches/hotfixes for V1.2.0
, those versions will be V1.2.1
, V1.2.2
and so on. And the next development version will be V1.3.0
.
At the same time assembly versions will also contain build number, like 1.2.0.76
and I want to show this version in UI like V1.2.0 (build 76)
. Build number will increment with each build (so it doesn’t reset to 0 when major/minor/patch version is incremented).
Branching model
As we give a try to trunk based development, we always create new branch for a feature/issue from master
branch. Use following template to name a feature branch HGBE-githubIssueNumber
(ex. HGBE-48
for work on https://github.com/Bounz/HomeGenie-BE/issues/48).
When the work on issue is finished create a pull request (PR) from that branch to master
. TeamCity will perform a build for that PR and run unit-tests. If everything is OK - merge pull request and delete feature-branch (GitHub offers you to do this after merging PR).
When work on version is finished (all issues targeting that version are done) - we will create a tag or version branch (from master
) and TeamCity will build that branch and publish a new release on the GitHub.