Versioning Strategy

The project uses Gitflow Workflow as its branching strategy. On the other hand, Boulder on K8S needs to keep up also with the upstream repository to avoid becoming obsolete. The following Git log graph depicts how we achieve this extra goal.

* 8b3555e9       (HEAD -> develop) Starting development of v1.1.0
*   f281f3ee     Updating to upstream version release-2020-03-16
|\  
| * 0dd8f41c     (tag: release-2020-03-16, upstream) ra: forbid mailto contacts that contain hfields (#4694)
| * 2bf12b93     Rename "authz2" types to just "authz" (#4701)
* |   6ff762be   Merge branch 'release/1.0.0' into develop
|\ \  
| | | * 6789d285         (tag: v1.0.0, master) Merge branch 'release/1.0.0'
| | |/| 
| | |/  
| |/|   
| * | 481dd785   (release/1.0.0) Releasing v1.0.0
|/ /  
* |   6e8afaeb   Merge branch 'feature/1' into develop
|\ \  
| |/  
|/|   
| * e019e01e     (feature/1) Feature development finished
| * d0876a5b     Feature development commit
|/  
* 9232f0e9       (tag: v0.0.0, tag: release-2020-03-03a) Fix admin-revoker argument check (#4693)

The project starts at some upstream version, release-2020-03-03a in this example, Git upstream history is pushed to the repository until this commit. Branches develop and upstream originates from this base version. The unchanged base version is tagged with v0.0.0. Development continues on the branch develop and feature branches originating from develop. The release process of version v1.0.0 starts from develop and progresses on the release branch release/1.0.0. Releasing v1.0.0 results in a merge commit to the master branch tagged with v1.0.0. The release branch is also merged into develop. New product version development should be based on the latest release of the upstream Boulder project. Boulder’s latest release history until the latest tag release-2020-03-16 is merged into develop and new product version development may be started.

Warning

Upstream tags should never be pushed to the Boulder fork repository to avoid version confusion.