We release from master. Push changes/merge pull requests as needed to master. CI process will post a snapshot build with changes. Be sure to verify snapshot build is OK even if you tested locally.

When ready for release edit CHANGELOG.md to include release notes for this release. Set the version number and date and push to master. Copy and paste the notes for current release for next step.

In Github UI, click on the Releases tab and add a new release. Label the release with the version number for the new release like "4.2.0". Paste the release notes from previous step into the description and add the release. This will create a tag in the repository which will fire off the CI process to build and post the release to bintray.

The release deployment process will post a p2 repository for the exact release name, and then update the latest and major.minor composite update sites to point to the new release. This allows users to either download a specific release or they can follow a specific version or just always get the latest.

Once the new release is out and confirmed, master should be updated for the next release. There is a script on root of the repository to assist with this:

./set-version.sh OLD NEW

This will find and replace the OLD version with NEW. So for example:

./set-version.sh 4.2.0 4.2.1

After running the command use git status and git diff to confirm the result looks correct then add/commit/push the changes. CHANGELOG.md should also be updated to start the section for the next release. This can be labelled "master" until we finish the next release.