Release strategy

The implemented release strategy fits a GitHub centered workflow. It’s cornerstones are:

• Releases should be in any case provide a stable version with no obvious bugs.
• Bugfix-Releases are addressing issues only, whereas new features are introduced within a proper Release.
• Concerning the numbering schema of releases and bugfix-releases:
  • vz.x is a feature-release
  • vz.2.y is a bugfix-release within the second feature-release
• After each new release (both feature and bugfix) a new branch for the next bugfix-release is created (vz.x => vz.x.1 or vz.x.y => vz.x.(y+1)) which operates as base branch for any further changes in this release. All dependency updates are done in this branch to ensure all dependencies are up-to-date before a new release.
• Supported projects are always on a release using git fetch && git checkout tags/v0.x.y-...

How To Pull Request (PR)

Depending on the type of your PR, you have to choose a different base branch.

• For a new feature, you should always use the master branch as base branch. Only features which depend on another (currently developed) feature should use the other feature branch as base.
• For a bugfix, you should use the latest bugfix-release tag as base branch. Since we only support the latest minor release (x) of the latest major (z) release, you should use the tag with the highest z, x and y. After your changes you have to actually create a PR. If approved by one of the admins (@eScienceCenter/spacialists), it is merged into master. But there is one exception for bugfix PRs. Before they are merged/rebased/whatever, a new release with a new tag (z.x.y+1) from to the top of this PR is created. Afterwards, the PR can be merged into master.

Hints

1. To help others to understand what you've fixed and to make it easier to include a changelog in the release, please update CHANGELOG.md with your changes.
2. To ensure the team is notified by your PR, @mention the spacialist team (@eScienceCenter/spacialists). If there is a specific member of the team, who should have a look at your PR, you can directly @mention them.

The actual development cycle is mostly relying on the branching and releasing strategy described here: https://hackernoon.com/a-branching-and-releasing-strategy-that-fits-github-flow-be1b6c48eca2