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.
