Making a security release

On some occasions you need to make a release that contains only one or a few critical fixes on top of your last release. One example of this is if you are working with the Drupal Security Team to make security release of your module, but your development branch contains significant changes since the last release or is not stable. In this case it might be best to provide a release containing just the code in the last stable release plus the fix.

The step-by-step instructions below are basically right, but this needs to be tested.

Outline:

1. create a branch from the last release tag, $TAG, name the branch something like $TAG-hotfix
2. commit the fix(es) to the branch
3. create and push the new release tag
4. merge the fixes back into the mainline branch
5. create a bugfix and/or feature release including the security fixes (possibly waiting after more time has passed).

So for a module with development branch 7.x-1.x, and an existing release tag 7.x-1.0, the actual git commands would look like this:

$ git checkout -b 7.x-1.0-hotfix 7.x-1.0
Switched to a new branch '7.x-1.0-hotfix'

$ git apply something.patch

$ git commit -am"critical fix"
[7.x-1.0-hotfix 2bd5131] critical fix
 1 files changed, 1 insertions(+), 1 deletions(-)

You may then need to do additional prep, such as editing the CHANGELOG to set version number or other similar minor fixups. Commit those, and then tag your release:

$ git commit -am"prep 7.x-1.1 release"

$ git tag -a 7.x-1.1 -m"7.x-1.1 release"

Now you push the new tag to the drupal.org repo so you can make your release:

$ git push origin 7.x-1.1

Now merge the changes back. It's important to use the --no-ff flag so that the merge commit is always recorded in your history. Once you do this there is no need to retain that branch, nor any need to push it to drupal.org, since it will just clutter the list of branches.

$ git checkout 7.x-1.x
Switched to branch '7.x-1.x'

$ git merge --no-ff 7.x-1.1

$ git branch -d 7.x-1.0-hotfix

$ git push

You will see that the most recent log message contains a record of the merge like:
Merge commit '7.x-1.1' into 7.x-1.x

Now, you may either immediately, or after additional testing or development, release your next version containing all the other fixes or features in your main development branch.

$ git tag -a 7.x-1.2 -m"release 7.x-1.2"

$ git push origin 7.x-1.2

This diagram shows how a git GUI tool like GitX presents the sort of history that would be generated by this workflow. You can see that the existence of the temporary hotfix branch is represented even though it was deleted: