First thing we do is to create a branch called "develop", off which almost all work is done.
- Tiny fixes that are just one commit, I usually do directly on the "develop" branch.
- Small tasks, that are usually completed within a day, and with a single contributor, I suggest branching off from "develop" into a kebab-case-name in the folder "dev/*".
- Bigger tasks, that might go on for several days and with more than one person contributing, I suggest branching off from "develop" into the folder "feature/*". What's important is to never have more than one of these long living branches, and that you often (at least daily) merge develop into the feature branch.
When the time come for us to do a release, we create a branch in the folder "release/*" called major.minor.x based on "develop". If we're about to release version 1.39 for example, the branch would be called "release/1.39.x". The 'x' is because the number of iterations that will be needed to stabilize the release is unknown at this point.
Once we have the branch we change the version number in the project to 1.39.0 and make an initial build. Immediately following that we update the version number to 1.39.1, so we know that and logs, tracking or bug reports saying 1.39.0 is that exact build that we just did. During the time between builds we have the odd revision number up until the point when we're doing the next build for testing. Then we update version to 1.39.2, make the build, and immediately followed by updating to 1.39.3. Get the drill?
Any work being done during the release process that isn't meant to stabilize the release should still be done in "develop", following to the bullet list above. It is also good practice to continuously merge the release branch back to "develop" to make sure that the issues are solved also there. Just make sure that you don't merge it back when it is an even revision number!
Finally, when we deem the product ready to meet the world, we merge the release branch to "master", making "master" always be the latest released version of the project. We also merge the release branch back to develop one final time where it is integrated with all work that might have been done there while stabilizing the release.
I hope this article can help some people to improve their release process! I'm also curious to learn if any of you have any practices you think are better or if you have any concerns with my proposed way of working. Let me know in the comments!
See also:
