Releases

Release

Planning

We use GitHub milestones for release planning (see milestones). So milestones are always exactly named like releases.

We do NEVER change milestones after a release - so our closed issues inside milestones are also our release letter.

How to release…​

Is described at release project page.

History

Finished releases, corresponding artifacts etc. can be found at releases.

We use closed milestones as release letters and link them inside the releases. For an example look at v0.13.1-server release

Branching model

We have following standard branches

• master
  Master branch is used for releases. Will always represent latest version and is always merged from develop or hotfix branch.

• develop
  Here the development of the next releases is done.
  For every new feature we normally create a corresponding feature branch with name pattern: feature-${issueNr}-${shortDescription}. For example: Issue #68 should have a feature branch named feature-68-optimize-codescan-result-report
  For minor changes we have a special minor change issue and also a corresponding minor change branch.
  Developers will create a PR (pull request) to merger their feature branch to develop branch, what will be done by an maintainer.

• hotfix
  We use this for urgent fixes of an already deployed version. It is only related to master (release) branch. E.g. we have released version 0.13.0 and started development of new features in a feature branch and descendants. After a while we have found a problem in the released version 0.13.0. In this case we merge master to hotfix fix the problem inside the hotfix branch, merge solution back to master and start a release of 0.13.1 as described at https://github.com/mercedes-benz/sechub/projects/1

• community
  We use this for integrating external contributions. All pull requests from external people shall go into this branch. We then can check for build failures etc. before merging into the develop branch.

Version numbering

We use v$1.$2.$3[-$type] as version template.

Semantic

$1 = major
$2 = minor
$3 = hotfix

$type = client|server (optional)

So for example a v1.5.0-client represents minor client release 1.5.0

Milestones

We use milestones to group issues. Same semantic as for releases is used, except no type is defined. So Milestone 1.0.0 represents a major change (SecHub became open source) and 1.1.0 will be a minor change, so normal feature development, non critical bug fixes etc.

If there are problems with releases the related milestone will be used for the hotfix milestone. E.g. When we got a problem with client 1.5.0 which is contained inside 1.0.0 milestone (see milestone text ) we would create milestone 1.0.1 and assign the bug issue to this milestone.

Milestones are used as release letters. Simply click on the milestone and look at closed issues inside.

Overview of released versions

Please look at https://github.com/mercedes-benz/sechub/releases