Branching

• update release notes:
  • check for missed important changes, check the formatting at http://buildbot.net/buildbot/docs/latest/release-notes.html
  • update the 'git log' command at the bottom to give explicit versions
• commit
• branch, using the long name for the branch

  git co -b buildbot-X.Y.Z
  

• add the branch to your git config for pushing to the organization repo
• switch back to master and fix up the release-notes:
  • copy master/docs/relnotes/index.rst to the proper version filename, and edit the version number (replace |version| with e.g., v0.8.6 twice). Add "This version was released XXX" as a reminder to fill in the date later.
  • delete all of the contents of master/docs/relnotes/index.rst and fix the 'git log' command at the bottom to point to v$justreleasedversion..master
• commit with -m archive release notes
• tag 'vA.B.C-pre' (it's important that the commit above come first!)

  git tag v0.8.3-pre -m "work begins on 0.8.3.." HEAD
  

  (where A.B.C is the expected next release, for the benefit of 'git describe'; no need to sign)
• push to the organization repo. You should see master, vA.B.C-pre, and buildbot-X.Y.Z updated.

Once the branch is open, merge frequently from the release branch to master, paying particular attention to the release notes (since changes to release-notes.rst in the branch should be reflected in x.y.z.rst in master). Do not merge from master to the release branch!

Releasing

• update release notes with any late-breaking changes and commit
  • in particular, add "This version was released $DATE"
• make a git tag:

  VERSION=v0.8.10; GPG_TTY=`tty` git tag -a -s $VERSION -m "TAG $VERSION"
  

• make a tarball for master and slave, to check that it works:

  for d in master slave; do ( cd $d; rm -f MANIFEST dist/*; python ./setup.py sdist --formats gztar,zip ); done
  

• install the tarballs somewhere to sanity-test them.
• push to github
• update the versioned relase notes in master to match master/docs/relnotes/index.rst on the branch
• for a release candidate:
  • put the tarballs at /home/buildbot/html/tmp and send the links to the mailing list
• for a real release:
  • cheeseshop - for master and slave: (eggs aren't supported)

    for d in master slave; do ( cd $d; rm -f MANIFEST dist/*; python ./setup.py register sdist --formats gztar,zip upload ); done
    

    note that these tarballs and zips will have different sums from those produced previously, but that the 'upload' command will not allow you to upload already-created files.
  • sign tarball: gpg -ba buildbot-N.N.N.tar.gz; also .zip
  • upload to all files + signatures to google code:

    sh common/gcode-upload.sh 0.8.2 djmitche GOOGLE-CODE-ACCESS-TOKEN
    

    check that the upload works - it often fails for the master tar.gz
  • update pypi
    • set the downloads link for each package to  http://code.google.com/p/buildbot/downloads/list
  • update Trac wiki, changing version numbers and the release date.
  • update google code
    • deprecate old downloads (click "Delete File", choose to deprecate)
  • make a docs tarball and a 'reference' (apidocs) tarball
    • check out the tag: git co v0.8.3
    • make the docs: cd master/docs; make
    • move master/docs/_build/html to docs/0.8.4 in the bbdocs repo
    • run add-tracking.py over all of the html files: find docs/0.8.3 -name '*.html' | xargs python add-tracking.py
    • run create-sitemap.py: python create-sitemap.py
    • add appropriate links in index.html
    • update the current link
    • push to bbdocs and pull it on the server
    • create a release link on BuildbotReleases, to the appropriate docs directory on buildbot.net
  • send mail to buildbot-devel
  • update freshmeat (login, click 'djmitche' at top, click Buildbot, click 'Submit Release')
    • you will need a prose description of the release
  • Mark the milestone as complete in Trac and create a new one.
    • If you do this in the roadmap, you can retarget all existing bugs to a new milestone
  • Add the Version to Trac and mark it as the default
  • Update the #buildbot topic
  • Build the tag on readthedocs.org
    • if this doesn't show up, double-check that the tag is on github
  • Verify any outstanding diffs and update the release date in master/docs/release-notes/x.y.z.rst on master
• Merge back to master, updating the release date in the docs.

Patch Releases

Patch releases are just like regular releases - made from the release branch. They should include any additional release notes at the top of the release-notes.rst, in a separate section, e.g.,

0.8.6p1
-------

In addition to what's listed below, the 0.8.6p1 release adds the following.

When performing the update, add the release date for the patch, as well as the new section, to the release notes in master/docs/release-notes/x.y.z.rst on master, and change the title and first sentence to reflect the most recent patch level.