| Home | Wiki | Use Cases | Work Flows | FAQ | Get Involved | Bugzilla | Build | Blog | Documentation

# Making A Release

Before the Release
Branch
Release
Upload
Announce

frysk is making point release, cut from the Git repository's `HEAD`, on the first Wednesday of each month. This lets us deliver new features quickly, with a relatively low overhead.

The relese branch is taken on the first Wednesday at `00:00 GMT`, just in time for frysk's Wednesday meeting. We then, during the meeting, conduct a brief review, check the NEWS file, and make a go/no-go decision. It is then pushed out, perhaps with a few minor fixes.

The process is also relatively simplistic. It assumes for instance:

- there's never a pre-release tar-ball
  that would require extra pre-release version numbers such as `0.1.90`... and then only at the last moment set the real version (`0.2`).
- if there's ever a need for a re-spin, it just gets assigned a patch-level number like `0.2.1` and use the original releases branch

## Before The Release

About a week before the release drop an e-mail to frysk@, and in the Wednesday meeting, reminding everyone:

- when the release is planned
- to add whats-new to the NEWS file

In the meeting, or on IRC, you might even collect suggestions and add them yourself. If you think of anything, just add it also.

Also, make sure you go to bugzilla and get a list of the bugs which have been fixed since
the last release. Add bugs which have not been mentioned to the NEWS file.
To do so go to the querey page and select FIXED in the "Resolution" section, and in the "Bug Changes" section put the date
of the previous release, and the appropriet date in the other box.
When the list comes up click on "Change Columns" at the bottom of the page and
make sure you select "Full Summary"

## Cutting the Branch

First, before cutting the branch, ask around for any late breaking NEWS additions.

Here's a suggested sequence:

- To make things easier, first lets set up a few standard shell variables; you'll want to set version to something more meaningful:

      cd frysk  (change to the directory where a fresh checkout of frysk is)
      version=0.3 ! ! ! change this
      echo $version
      date=`date -u +"%Y.%m.%d"`
      echo date=$date 1>&2
      shar1=`git-rev-list --before=$date -n1 HEAD`
      echo shar1=$shar1 1>&2
      branch=frysk/$version
      echo $branch

- Next we create a branch (frysk release branches are named frysk/<version>), and push that upstream:

      echo branch=$branch shar1=$shar1
      git branch $branch $shar1
      git push origin $branch

- Then, we update the version number of the branch, and edit the NEWS file to state that this is a release, and push that:

      git checkout $branch
      echo $version > frysk-common/version.in
      cat frysk-common/version.in
      $EDITOR NEWS
      git add frysk-common/version.in
      git add NEWS
      git commit -m "Update version.in and NEWS for release $version"
      git push origin $branch

- And finally we update the mainline so its version.in and NEWS file are ready for the next release.

      ... in mainline ... (git checkout ???)
      echo $version.50 > frysk-common/version.in
      $EDITOR NEWS
      ... start a new section for the next release ...
      git add frysk-common/version.in
      git add NEWS
      git commit -m "Update version.in and NEWS for release $version + 1"
      git push origin

The branch can then be checked out by everyone and build locally. Of course the keen will have already checked out the branch point using something like:

    git checkout `git-rev-list --before='00:00 GMT' -n1 HEAD`

## Making the Release

Here's a sequence for releasing frysk, we're assuming that $version was set above:

- First lets find the shar1 of the branch head (so that it can be refered to later), and the corresponding release tag:

      echo branch=$branch
      shar1=`git-rev-list -n1 $branch`
      echo shar1=$shar1
      release=`git show $shar1:frysk-common/version.in`
      echo release=$release

- Then create a tar-ball using that shar1 marker:

      rm -rf frysk-$release
      git archive --prefix=frysk-$release/ $shar1 | tar xpf -
      tar cfj frysk-$release.tar.bz2 frysk-$release

- as a sanity check try to build the tar-ball locally:

      rm -rf build-$release && mkdir build-$release
      ( cd build-$release \
        && bunzip2 < ../frysk-$release.tar.bz2 | tar xpf - \
        && mkdir build \
        && cd build \
        && ../frysk-$release/autogen.sh \
        && make -j2 )

- finally, assuming the results are good, tag the release and push it:

      git tag -u <gpg-name> -m frysk-$release frysk-$release $shar1
      git push --tags

## Upload to Sourceware

You might need access to sourceware for this:

    chmod a=r frysk-$release.tar.bz2
    scp frysk-$release.tar.bz2 'sourceware.org:~ftp/pub/frysk'
    ssh sourceware.org 'rm -f ~ftp/pub/frysk/.message'
    cat <<EOF | ssh sourceware.org 'dd of=~ftp/pub/frysk/.message'

                Frysk $release

        `md5sum frysk-$release.tar.bz2`
        $shar1   GIT SHAR1

    EOF
    ssh sourceware.org 'chmod a=r ~ftp/pub/frysk/.message'

## Announce the Release

Some people like to immediatly post the announcement, while others prefer to delay it a day or so giving the distros a chance to prepare local frysk packages. Either way, the announcement should at least include:

- All the contributors to this release (you can get this by going through GIT and, perhaps, the `ChangeLog` files; something like: `git-log --after=frysk/0.2 --pretty=format:"%an %ae" | sort -u`
- The contents of whats new section lifted verbatum from the NEWS

The announcement might also include:

- Where to download frysk
- file check-sums
- a very brief description of frysk

## Update Your Distro

Update distro(s) you have access to:

- Fedora: Instructions