Skip to content

BuildingARelease

Jump to bottom
Vladimir Vuksan edited this page Mar 23, 2015 · 9 revisions

Table of Contents

Pending changes to build and release system

Please be aware that these things may change in future releases:

  • libmetrics/configure.in is to be merged into the main configure.in (on dpocock branch)
  • tighten the integration between the new Ganglia web code and the monitor-core repo
    • currently in different repos
    • currently web has a different Makefile/build system
    • also consider making web entirely independent of the main project
      • if so, web should adopt a new minor version number higher than the current Ganglia release, such that package upgrades will work
  • automatically derive config.in values from tag (or do the opposite)

System requirements

  • Releases are built on Debian squeeze (specifically, an amd64 64 bit machine)
  • The most convenient way to replicate the environment is:
 apt-get install autoconf automake pkg-config libz-dev libtool ncompress make gcc git libexpat1-dev libapr1-dev libconfuse-dev libpcre3-dev rrdtool gperf
  • Other packages may also be needed: please add them to the list above
  • As of 3.3.7, the git2dist tool is used, fetch it like so:
 mkdir ~/ws
 git clone git://git.code.sf.net/p/git2dist/code ~/ws/git2dist

Steps

In the steps below, examples are given for building a 3.3.2 release.

If necessary, create a branch

If it is a bug fix release, we only update the revision number (e.g. 3.3.1 + bug fix = 3.3.2). If it is a minor (e.g. 3.3.x -> 3.4.x) or major (e.g. 3.3.x -> 4.x.x) release, we must create a new release branch in git, e.g. 

 git pull
 git checkout master
 git branch release/3.4
 git checkout release/3.4

Make sure the work is done on the desired release branch 

 git pull
 git checkout release/3.3

Cherry pick any fixes

If necessary, cherry-pick any final fixes from master: 

 git cherry-pick xxxxxx
 git push

where xxxxxx is the commit ID of the bug fix to cherry-pick.

Review the diff

Review the changes from the last release, e.g. if the last release was 3.3.1: 

 git diff 3.3.1

Look for anything that might impact binary compatibility with existing 3rd party modules, etc. Such things really should not be in a bug fix release, they should go in a minor release (as discussed above)

Review log, update changelog

Run git log (from the previous release) and note all the changes, add them to the changelog (where is it now? couldn't find it in git for monitor-core)

Update version in configure.in

Update monitor-core/configure.in, in particular: 

 GANGLIA_MAJOR_VERSION=3
 GANGLIA_MINOR_VERSION=3
 GANGLIA_MICRO_VERSION=2

and commit that change together with change log: 

 git add configure.in Changelog
 git commit -m 'Prepare v3.3.2 release'
 git push

bootstrap, build a tarball, test it

The git2dist tool automates all of these tedious steps now

It can be run like so: 

 ~/ws/git2dist/git2dist git2dist.rc 3.3.2
  • It will do a fresh clone from github and build from there to make sure everything is really on github
  • It does the bootstrap
  • It builds a tarball
  • It unpacks the tarball and does a compile
  • It performs basic tests to see if a valid binary exists (using ldd)

test the tarball again

  • extract to /tmp/something
  • cd /tmp/something
  • diff tree content (find /tmp/something -type f) against the content of the previous release tarball (tar tzf)
  • see [ReleaseTesting](ReleaseTesting) for more test details
If testing reveals a problem, throw away this clone, go back to the development phase and start the release process at step 1 when ready.

Tag the git2dist temporary clone

If the tarball is good, tag the clone that was made by git2dist: 

 git tag -s -m 'Tag v3.3.2' 3.3.2
 git push --tags

Upload

Upload the tarball to sourceforge or github download page.

Announce

  • Update other web sites (e.g. ganglia.info).
  • Announce it on the mailing list, publish:
    • the checksum,
    • the commit number of the tag,
    • sign the email with the same PGP key used to tag
    • download links (link to the file list, not directly to the tarball, so that someone clicking the link will see any more recent tarballs if they exist)
Clone this wiki locally