Process for patch releases

This document describes the process for patching the releases if needed. The same process can be followed to produce an incremental release over a previously released version.

Background:

Until last year, we always released newer versions of DROID from the master branch, however the slf4j vulnerability issue saw us in a situation where we needed to release a patch on an existing release. It is not always possible to do this at a short notice from the master branch due to a variety of reasons. We also saw a need to patch a release version as there was an uncaught bug which was shipped. These incidents prompted us to start thinking about having the ability to release a patch over a previous release at any time with a reasonably quick turnaround.

Following picture depicts the process for patch creation and release over an existing major version. Each steps along the process is detailed below. The version numbers used in the document (as well as shown in the picture) are from current timeline, however the process will stay the same for any subsequent patch release as well.

Situation: We have shipped a major release of DROID (e.g. v6.6.0) and a bug is found which we need to patch. There are no additional commits in master since the release.

This is a simple situation where an incremental release or patch can be simply shipped from the master branch after applying the bugfix in master

Situation: We have shipped a major release of DROID (e.g. v6.6.0), there are changes made to master since the release and a bug is found which we need to patch.

Step 1. Create a new patch release branch (e.g. patch-6.6.x)

Whenever we release droid, there is a tag created in github repository. Create a new branch from this tag. Lets call it patch-6.6.x branch. This branch now serves as main branch for any patch releases incremental to v6.6.0. Once the branch is created, adjust the POM files in this branch to indicate it to be the next development version (e.g. 6.6.1-SNAPSHOT)

Step 2. Create a feature or bugfix branch and implement a fix

• Create a new branch (e.g. issue-900-fix-for-missing-hash-column) from patch-6.6.x
• Implement fix or improvement in this branch
• Open a pull request to merge bugfix back into the patch branch (note: A new PR, by default attempts to merge into master, update the PR so that it is merging to "patch master")
• Once the PR is approved, merge it (but do not delete the bugfix branch just yet!!)

Step 3 Release candidate, testing and releasing

• Go through the maven release process to create a release candidate (e.g. 6.6.1-rc) from the patch master
• Test the release candidate following a normal testing regime
• If you find any issues, and it is critical, go back to Step 2 and fix that issue as well
• If you find an issue which can be deferred for future, continue with the release
• Perform maven release process to generate a release (6.6.1)

Step 4 Merge changes from patch into master

• To keep the master up-to-date with latest bugfix, you can merge the patch branch back into master to bring it up to date
• At this point, the bugfix branch can be deleted to cleanup the repository but do not delete the patch master (patch-6.6.x)

Housekeeping on the patch branch

If another patch is needed at a future date, the patch master can be used as it is. It is possible that the patch master may have old dependencies which could fail the build as and when vulnerability database is updated. If you face this, please update the dependencies accordingly but no other code change should go in this branch. If and when a new major release has been released from the master (e.g. v6.7.0) the patch master (patch-6.6.x) can be deleted.

All along this timeline, we assume that new features, improvements etc are continually being added to the master, none of which should make their way into the patch branch. Please do not merge master into the patch branch ever!!