Difference between revisions of "ReleaseEngineering"

From Request Tracker Wiki
Jump to navigation Jump to search
(→‎• Generate docs: Update option name)
 
(Flip path names around for docs and release-notes)
Line 26: Line 26:
     make snapshot
     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:
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
     gpg --detach-sign rt-3.8.18.tar.gz
     sha1sum 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).
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 ===
=== • Sanity check tarball and signature ===
Line 58: Line 58:


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


Commit the changes to the bestpracticalsite repo.
Commit the changes to the bestpracticalsite repo.
Line 67: Line 67:


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


Commit the changes to the bestpracticalsite repo.
Commit the changes to the bestpracticalsite repo.

Revision as of 19:57, 12 August 2013

• Create releng branch

   git checkout -b 4.0.14-releng 4.0-trunk

• If necessary, git cherry-pick -x sha1 to pull changes from trunk to branch

• Make sure translations are uploaded to Rosetta with enough time to be translated

• Import translations

• Check if jsmin should be updated on download.bestpractical.com/mirror/

• 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.

• 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