Git merge branching good practices
Each GeoNetwork version is composed on three numbers separated by a dot: $major.$minor.$patch.
-
Changes in $major number usually comes when a new big feature is added or when there is some break on the backwards compatibility.
-
Changes in $minor number means new features.
-
Changes in $patch number means new bug fixes.
For each new minor release plan (4.2, 4.4, 4.6) we will fork main branch into a branch named $major.$minor.x and freeze the code accepting only bug fixes for some weeks. Once this branch is well tested, we will release the final version (4.2.0, 4.4.0, 4.6.0).
This releases will still receive bug fixes in the form of patch releases (4.4.1, 4.4.2,…), but no new features. New features will only come with minor releases.
We expect to release a new minor version every six months, but as usual, the real frequency will be determined by the needs and the amount of contributions we receive. Contributions following the community guidelines are welcomed. More contributions, more releases.
GeoNetwork has a separated git branch per minor version: 4.0.x, 4.2.x, 4.4.x,… Then there is another branch for the features: main. Usually you shouldn’t trust that the main branch is stable. Use it on production at your own risk.
We have a nickname for active branches:
-
latest: the main branch used for development
-
stable: the 4.2 branch (from the last minor release) recommended for production environments
-
maintenance: the 3.12 branch (from the last major release) that is still available for use but will only be updated in an emergency
The branches are being merged by backporting pull-requests, or cherry-picking individual commits from main. This means, all bug fixes on main should always end up in latest version branch, if applies.
We will always try to fix stuff only the last numeric branch (last known release) and main. Fixes for older branches can be made, but there is no expectation for porting bug fixes backwards. If a developer requests a PR for a fix on an older branch, it is their responsibility to request first a PR to main, and the backport to rest of version branches.
When adding a new bug fix you fork the master branch. Once your bug fix is in place, you create a PR and wait for approval. This waiting can be as active as you want.
Once your PR gets approved, fork the latest stable version (4.6.x, 4.8.x,…) and cherry pick the change, if it applies to the version branch. Do another PR and wait for approval. Refer to previous PR on this PR. This waiting can be as active as you want.
When adding a new feature you fork main branch. Once your feature is in place, you create a PR and wait for approval. This waiting can be as active as you want.
You start with the main branch. Then, you fork to a "release version" branch: "$major.$minor.x" like "4.4.x".
-
In the beginning the main and the release version branch are the same.
-
At this point you must return to the main branch and update the
pom.xmlproject.version information like "4.6-SNAPSHOT".
Then you start committing and pushing bug fixes to the release version branch. At the same time, there are other commits pushed to main. These other commits are not for the release version branch, but for a future version, as they contain new features.
You will never merge from main to a release version branch, as you do not wish to accidentally add new features to a release version branch.
The release version branch will obtained all the latest bug fixes back ported or cherry-picked from main.
Ask on one of our mailing lists: https://geonetwork-opensource.org/community.html