Release process

There are 3 branches: This page outlines the steps required to generate a new release.

The following brancher exist per default:

• develop (might be removed in the future)
• master
• stable

Each step is defined below in detail. Creating a new stable release has the following steps:

• Merge the master branch into the stable branch
• Test until most are reasonably satisfied
• Tag the release in the stable branch
• Update the change log
• Regenerate and push user documentation
• Push a new zip file
• Announce the new release

Merge master into stable

The following branches are available in the nagios-cloudwatch repository:

• master branch is the branch where we actively develop code on
• stable branch is the branch that contains stable releases for normal users

New development takes place on master until the developers decide it is time for a new stable release. At that point we merge the current master branch into the stable branch, ask developers and users to test the stable branch, and once we have rough consensus we create a new release that we deploy into the stable branch.

At the time, only Magnus Lübeck can merge and push the latest stable release.

NOTE: The steps here assume you have write access to the repository and have already setup a clone of maglub/nagios-cloudwatch.

To create and publish a new stable release go through the following steps:

   git pull 
   git checkout stable
   git merge master

This ensures your local clone is up to date with maglub/nagios-cloudwatch, changes the working copy to stable and then merges all changes that were applied from master into stable.

Update the version numbers in the .version file.

Then, update the version number in the VERSION file and finally commit the updates:

   git stage .version
   git commit -m "new stable release $(cat .version)"
   git push origin stable

The stable.tar.gz link on the GitHub page will automatically be updated to the latest stable.

Tag the release in the stable branch

When it is time to finalize the release, do the following:

  git tag -a $(cat .version) -m "New stable release $(cat .version)"
  git push origin $(cat .version)

The stable.zip link on the GitHub page will automatically be updated to the latest stable, and the releases page will automatically list the current and the previous versions for later reference.

Update the change log

Update the changelog page

• Undo the changes to your local repository

git reset --hard HEAD
git status

Announce the new release

Send a message to both the piLogger Users and piLogger Announce mailing lists. Only authorized senders can post a message to the lists, currently the list of authorized senders includes all user with GitHub write access. However, these senders may still need to log into the mailing list control panel to approve their message.