Release Building Script

Release Building Script

make_release.sh [-v VERSION] [-f PREV_BRANCH | -t | -b] [-F PREV_VERSION] [-n] [-p]
   VERSION is auto-detected by default and is based on the currently checked out branch.
   PREV_BRANCH is auto-detected by default but that isn't reliable. Include remote name!
   PREV_VERSION Is auto-detected by default and is based on the PREV_BRANCH's name.
   -n specifies that you don't want an upgrade script to be auto-generated.
   -p specifies that this is a preview build.
   -t turns on tag only mode.
   -b turns on build only mode.
   NOTE: -t and -b override PREV_BRANCH/PREV_VERSION, but -b overrides -t.

When building a release you should have git2cl in your PATH as well as
all packages needed for building i18n and staff clients.

Usage examples:

Tagging a major version root (no need for git2cl/staff client deps):

    git checkout -b rel_X_Y origin/master
    build/tools/make_release.sh -t

Building a release:

    git checkout -b rel_X_Y_Z rel_X_Y
    build/tools/make_release.sh

Building a new major release:

    git checkout -b rel_X_Y_Z rel_X_Y
    build/tools/make_release.sh -f origin/tags/rel_U_V_W

Specifying a version outright:

    build/tools/make_release.sh -v X.Y.Z

Very Specific Example: Building the 2.2 RC1 release:

    git checkout -b rel_2_2_rc2 origin/rel_2_2
    build/tools/make_release -f origin/rel_2_1 -n -p

Release files are placed in a "release" folder one level up from your git
root directory.

Nothing is pushed to remote servers, but dojo and xulrunner files may be
downloaded. Dojo to install in the release tarball properly, xulrunner for
building the staff client and avoiding issues with xulrunner changes if
end-users build a custom staff client (say, for autoupdate purposes).

Signed-off-by: Thomas Berezansky <tsbere@mvlc.org>
Signed-off-by: Dan Scott <dan@coffeecode.net>