...
| Section | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...
| Info | ||
|---|---|---|
| ||
The release branches mirror the versions available on the ftp site and will be fully tested. To checkout a published release use the release tags. All new code should be placed in a 'feature' branched from 'develop'. Don't create a new feature from a release branch. Only hotfixes should branch from releases (see branching model below). |
Checking out a specific release
All releases are "tagged". The tags are applied to the git commit that correspond to the tarfiles made available via the OpenIFS ftp site.
Checking out a specific release is very easy, just specify the release, e.g.
| Code Block |
|---|
% git clone ssh://git@software.ecmwf.int:7999/oifs/oifs40r1.git oifs40r1v1.1
......
% cd oifs40r1v1.1
% git checkout v1.1
Note: checking out 'v1.1'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout. |
The warning about the 'detached HEAD' state is because the tagged commit is not the most recent commit in the repository.
Hotfixes
Hotfix branches are one reason to checkout a specific release. Hotfix branches should only be created from release branches. They should be merged into the same release branch (and merged to 'develop' if not already).
See the branching model below.
The minor release number e.g. 1.x should be incremented for minor releases after hotfix branches are applied.
Branching model
OpenIFS has a small number of developers and a small number of releases. In this scenario, a single 'develop' branch with multiple release branches works well. The branching strategy is similar to the "gitflow" model but with modifications for multiple supported releases, which gitflow does not allow for.
| Gliffy Diagram | ||||
|---|---|---|---|---|
|
Notes:
- All new code should branch from the main 'develop' branch as 'feature' branches e.g. feature/update-physics.
- Release branches are created from develop. From then on release branches should be fixes only, no new features. Fixes should be merged back to the main develop branch.
- Production releases should be tagged on the release branch (never the master branch, unlike the 'gitflow' model).
- Hotfixes should branch from their respective release only, and if necessary be merged into the develop branch.
- The master branch is largely redundant in this model. Only major releases, v1, v2, and not minor releases should be merged to master since v1.1 might be released after v2 which would cause difficulties merging to master.
...