ReleaseEngineering

• Create releng branch

   git checkout -b 4.0.14-releng 4.0-trunk

• If 3.8, update configure.ac for the correct version

  perl -pi -e s/3.8.HEAD/3.8.18/ configure.ac
  git commit -m 'Bump version for 3.8.18' configure.ac

• Tag the release

  git tag -sm 'release 4.0.14' rt-4.0.14

• Make the archive

   rm -rf autom4te.cache
   ./configure.ac
   make snapshot

This will build you a snapshot tarball, GPG sign it and give you SHA1 sums. On 3.8, you'll need to sign and generate SHA1 sums yourself:

   gpg --detach-sign rt-3.8.18.tar.gz
   sha1sum rt-3.8.18.tar.gz*

Do not skip reconfiguring, as it ensures you have a fresh build and Makefile. This is especially important if you're releasing 4.0 and 3.8 at the same time from the same clone (i.e. rolling security releases).

• Sanity check tarball and signature

This should include running tests from inside the tarball (with MySQL or Pg), verifying the embedded version (esp. on 3.8), checking that RT starts up on a fresh database, and checking the signature.

It's nice to let other folks kick the tires as well.

• Upload it

   chmod a+rx rt-4.0.14*
   scp -rvp rt-4.0.14.tar.gz* download.bestpractical.com:/opt/web/hosted/download.bestpractical.com/html/pub/rt/release/
   scp -rvp rt-4.0.14-third-party-source.tar.gz* download.bestpractical.com:/opt/web/hosted/download.bestpractical.com/html/pub/rt/release/third-party-source/

When making a non-developer release, files live in pub/rt/release and you need to make sure to update the rt.tar.gz symlink:

   ssh download.bestpractical.com ln -svf /opt/web/hosted/download.bestpractical.com/html/pub/rt/release/{rt-4.0.14,rt}.tar.gz

As soon as you upload a new version into pub/rt/release/, it will be displayed on the corporate site's front page and RT product page.

Developer releases such as RCs go in pub/rt/devel/.

• Generate docs

From inside a git clone on at least 4.0-trunk:

devel/tools/rt-static-docs --source rt-X.Y.Z.tar.gz \
                           --to /path/to/bestpracticalsite/web/static/docs/rt/X.Y.Z

Commit the changes to the bestpracticalsite repo.

Diff with previous version docs to check that nothing horrible changed.

• Update release notes in bestpractical.com repo

       rsync -av --delete release-notes/[1-9].*.{release,changes} \
                          bestpracticalsite/web/static/release-notes/rt/

Commit the changes to the bestpracticalsite repo.

• Pull bestpractical.com live with updates

See checkmarkable.

• Update and release RT::Client::CLI

You may skip this if bin/rt.in is unchanged from the last RT release (and RT::Client::CLI is up to date with the last release).

   cd RT-Client-CLI/
   ./devel/import-rt
   git diff
   git commit -am 'Update to 4.0.x'
   git push
   milla authordeps | cpanm
   milla test
   vim Changes   # add notes to Changes file under {{$NEXT}}
   milla release # specify correct 4.0.x version

The last step will increment version numbers, tag, commit, upload to cpan, and push it all to git, with a prompt or two in between.

• Cleanup and preserve history

For stable RT releases after 3.8:

   git checkout 4.0-trunk
   git merge --no-ff 4.0.14-releng

Replace 4.0-trunk with the appropriate trunk branch (e.g. master, 4.2-trunk, etc).

For RT 3.8:

   git checkout 3.8-trunk
   git merge --no-commit --no-ff 3.8.18-releng
   git checkout HEAD -- configure.ac
   git commit
       Note in message that you undid the version bump from the branch