From 8bb5406f42d89c00459c29169261f69ef9204402 Mon Sep 17 00:00:00 2001 From: Samuel VERSCHELDE Date: Mon, 20 Jul 2020 17:14:51 +0200 Subject: [PATCH] Update develprocess.md Add naming conventions for tags and branches on the `xcpng` github org. --- docs/develprocess.md | 57 +++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 56 insertions(+), 1 deletion(-) diff --git a/docs/develprocess.md b/docs/develprocess.md index b337ee7b..d95e39d3 100644 --- a/docs/develprocess.md +++ b/docs/develprocess.md @@ -108,6 +108,61 @@ Our policy is to upstream everything if possible. However, there are some except ### How to help at development It all depends on your skills and areas of interest so it's hard to tell specifically in advance. Having a look at the open github issues and pick one () could definitely help. Else, maybe there's a specific topic that you would want to help improve. Even if you don't know where to start, just come and talk with us (see "Where discussion happens" above). +## Tags, maintenance branches in our code repositories + +Objectives of the branch and tag naming conventions: +* always know how to name tags and maintenance branches depending on the situation +* easily identify maintenance branches for a given release of XCP-ng, based on their name +* know what branch to develop the next version on +* for our tags and branches that have been developed from upstream branches or tags, document the upstream branch names through our branch and tag naming + +First question to ask ourselves: **who is the upstream for the software**? + +### 1. We are upstream + +Example: `xcp-emu-manager` +* Tags: `vMAJOR.MINOR.PATCH` (`v1.1.2`, `v1.2.0`...) +* Maintenance branch if needed: `VERSION-XCPNGVERSION`. + * We don't need to create the maintenance branch in advance. Not all software gets hotfixes. + * `VERSION` is the version we branched from: + * If possible `MAJOR.MINOR` (`1.1`, `1.2`) + * ... Unless we tagged the project in a way that would make this ambiguous. In that case, `MAJOR.MINOR.PATCH` (`1.1.1`, `1.1.2`...). + * `XCPNGVERSION` is the two-digit version of XCP-ng: `8.1`, `8.2`... + * Examples: `1.1.2-8.0`, `1.2-8.2`... +* Next release developed on: `master` + +* Tag: `v1.2.0` +* Maintenance branch: `1.2-8.2` + +If for any reason we decide to release a newer version of the software as a maintenance update, then: +* We stop updating the existing maintenance branch +* Further hotfixes would come from a new maintenance branch created from the appropriate tag. + +Special case: VERSION and XCPNGVERSION are always the same (example: `xcp-ng-release`). Then: +* Tags: `vXCPNGVERSIONFULL` (`v8.2.0`) +* Maintenance branch if needed: `XCPNGVERSION` (`8.2`) + +### 2. We are downstream + +Examples: `host-installer`, `sm`... +* Tags: + * We tag when we release a new version of XCP-ng: `vUPSTREAMVERSION-XCPNGVERSIONFULL` (`v1.29.0-8.2.0`) + * Then we use the maintenance branch but don't tag anymore (each build pushed to koji already acts as a sort of tag). If we *really* wanted to tag for patch updates from the maintenance branch, we could increment neither `UPSTREAMVERSION` nor `XCPNGVERSIONFULL` so we'd have to add yet another suffix. Eg. `v1.29.0-8.2.0-3.1` where `3.1` would be the `Release` tag from the hotfix RPM. +* Maintenance branch: `UPSTREAMVERSION-XCPNGVERSION` (`1.29.0-8.2`) + * When we are downstream we always create a maintenance branch for a given XCP-ng release +* Next release developed on: next maintenance branch directly (`1.29.0-8.2`) + +If for any reason we decide to release a newer version of the software as a maintenance update, then we'd create new tag and a new maintenance branch that match `UPSTREAMVERSION` (that changes) and `XCPNGVERSIONFULL` (that doesn't change) + +Special case: the upstream version and the XCP-ng version are always the same (example: `host-installer`). Then: +* Tags: `vXCPNGVERSIONFULL` (`v8.2.0`) +* Maintenance branch: `XCPNGVERSION` (`8.2`) + +#### About upstream branches + +* If we get the sources from XS SRPMs, then we import them to a branch named `XS` and tag `XS-XSVERSIONFULL` (`XS-8.2.0`). Example: `host-installer`. +* If we forked a git repository, we don't need to push the upstream branches or tags to our own fork. However it could be a good habit to track maintenance or hotfix branches for changes. + ## RPM packaging Creating packages that can be installed on the user's system is called **packaging**. @@ -843,4 +898,4 @@ sync;fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test * Installation of guest tools on new Linux VM * Windows VM from an upgraded pool, with older guest drivers not updated * Update existing Windows guest drivers -* Installation of guest drivers on new Windows VM \ No newline at end of file +* Installation of guest drivers on new Windows VM