User Tools

Site Tools


Build a release candidate

These instructions must be executed in the correct order as part of the Release procedure. Before a release candidate can be built, the release process must have been started.

In this document:

  • X.Y is the version of Serval Mesh being released
  • X.W is the version of the prior release (usually W=Y-1).

The following commands are all executed starting with the current working directory in an up-to-date Git clone of the Batphone GitHub repository:

Ensure a new release candidate is needed

The release branch must either contain no release candidate yet (ie, be freshly forked from the Batphone Git development branch):

$ git describe origin/release-X.Y

or there must have been changes (commits) made since a previous release candidate:

$ git describe origin/release-X.Y

The only valid results for Git describe of the release branch are:

  • X.Y–preN or X.Y–preNC–gXXXXXXX — there has been no release candidate for version X.Y yet
  • X.Y.RCNC–gXXXXXXX — there have been N release candidates to date for version X.Y and there have been C commits since the latest (N-th) candidate

Any other result from the Git describe command indicates that the release process has not been followed properly; consult a senior developer. In particular, a result of X.Y.RCN without the –C–gXXXXXXX suffix indicates that there have been no changes since the last release candidate, so a new candidate is not needed.

Tag the release candidate

Tag the HEAD of the release branch as the N-th release candidate (the following example uses N=3) and do not push to GitHub:

$ git tag --annotate --message='Release candidate' X.Y.RC3 origin/release-X.Y

The --annotate option is necessary to annotate the tag, otherwise it will be overlooked by the Git describe command, and the instructions above and in Discover the release status will not work.

Check out the release candidate

Check out the release candidate:

$ git checkout --quiet X.Y.RC3
$ git submodule --quiet update

(This will put the Git clone into “detached head” mode, and the --quiet option suppresses Git's warning message about that.)

Ensure there are no local changes and the version string is correct:

$ git status --short
$ git submodule --quiet git status --short
$ ./jni/serval-dna/

Build and test native Serval DNA

Build and test a native servald executable by following the instructions in jni/serval-dna/ (skip the Download step):

$ cd jni/serval-dna
$ less
$ autoreconf -f -i
$ ./configure
$ make
$ ./tests/all
$ cd ../..

Ensure that all automated tests pass. If any fail, then the release cannot proceed.

Build OpenWRT Serval DNA

Build the serval-dna package for OpenWRT by following the instructions in jni/serval-dna/doc/, using the development feed from the current clone:

$ D="$PWD"
$ cd SOMEPATH/12.09/openwrt
$ sed -i -e '/ serval /s/^/#/' feeds.conf
$ echo "src-link serval $D/jni/serval-dna/openwrt/packages" >>feeds.conf
$ ./scripts/feeds update serval
$ ./scripts/feeds install -p serval serval-dna
$ make menuconfig
... enable Network -> Mesh networking -> serval-dna ...
$ make
$ cd "$D"

If there are any build errors, then the release cannot proceed.

Build and sign the APK

Build a Beta release by following the instructions in doc/

$ less doc/
$ ant beta

Push the release candidate tag

Once all the above steps have completed successfully, push the release candidate tag to GitHub:

$ git push origin X.Y.RC3
Writing objects: 100% (1/1), 173 bytes, done.
Total 1 (delta 0), reused 0 (delta 0)
   hHhHhHh..hHhHhHh  X.Y.RC3 -> X.Y.RC3
content/servalmesh/release/build_a_release_candidate.txt · Last modified: 07/01/2015 09:10 by Andrew Bettison