diff --git a/README.md b/README.md index 67ffd9a74ea7959f9f35874b17161d59152abcd3..885f9bc2c580668a93494d2a8bb52c79f8e4650f 100644 --- a/README.md +++ b/README.md @@ -22,6 +22,10 @@ https://nynjadev.atlassian.net/wiki/spaces/SER/pages/119046318/Servers MQTT API Port: 1883 REST API POrt: 8888 +Branching +--------- +[Branch and release handling](./doc/branch-handling.md) + Developers Setup ---------------- diff --git a/doc/branch-handling.md b/doc/branch-handling.md new file mode 100644 index 0000000000000000000000000000000000000000..e9a74edf09be7581e27197e22af17c4a73ce62ac --- /dev/null +++ b/doc/branch-handling.md @@ -0,0 +1,51 @@ +Branch and release handling +=== + +The repository has been developed with different branching +strategies. This document aims to unify the branch and release +handling going forward. + +Branches +--- + +The `master` branch is the main branch, and should in principle be +releaseable at all times. + +All work should be done in feature branches based on the `master` +branch, and anything merged back to `master` via pull requests, must +be ready to be deployed. + +If a feature is developed in a branch, and the developer wants to +merge it back to `master`, but it isn't ready to be deployed, it can +still be merged back to `master` if it is duly turned off by some +configuration or similar. + +A long-living feature branch can be used for large features with +multiple sub-features, but it is better to divide this into several +configurable feature branches. Remember that master is supposed to be +releasable. + +Releases +--- + +When preparing for a release, a release candidate is made in the form +of a tag on the `master` branch. Preferably on the HEAD, but not +necessarily so. + +The release candidate tag should be of the form `1.1.2-rc` + +If necessary, fixes can be added to the release candidate by branching +out from the tag, but do try to avoid this. Strive to move the release +candidate forward in the history of `master` instead by adding a new +release candidate tag of the form `1.1.2-rc-2`. + +When release testing is done, the release is tagged on the form +`1.1.2`. The release is built using this tag. + +After the release is done, if the release tag is not in the history of +`master` (e.g., if there was a branch with fixes) the release tag +should be merged to master after the release, to ensure that released +versions is always in the history of master. + +In the normal case, the release does not need to be be merged to +master since it is a tag in the history of master.