wiki:CuttingReleases

Branching

  • update release notes (master/docs/relnotes/index.rst):
  • commit
  • if making a full (not beta) release:
    • make a branch using the long name for the branch
      git checkout -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.
    • back in index.rst,
      • delete all of the contents
      • fix the git log command at the bottom to point to v$justreleasedversion..master
      • add a link to the new file in the "Older Versions" section
  • commit the change git commit -m "archive release notes" -a
  • tag vA.B.C-pre (it's important that the commit above come first!), if not releasing a beta. For example:
    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 relnotes/index.rst in the branch should be reflected in relnotes/x.y.z.rst in master).

Do not merge from master to the release branch!

Releasing

For the GPG operations here, use your own GPG keys. If you are new to releasing Buildbot, ask the previous releaser to send a signed message including your key fingerprint.

@djmitche and @tardyp use keybase to store their public keys. Here is a step by step on how to generate keys suitable to sign git tags to github: https://github.com/pstadler/keybase-gpg-github

  • blow away the node caches and other temporary stuff:
    git clean -xdf
    
  • call the release scripts (this will create the wheels, tarballs, and run the e2e tests):
    make release VERSION=0.9.4
    
    Then upload to pypi
    twine upload --sign dist/* 
    
  • push to GitHub
  • update the documentation (not for betas)
    • update Trac wiki, changing version numbers and the release date.
    • check out the tag: git checkout v0.9.4
    • make the docs: cd master/docs; make
    • move master/docs/_build/html to docs/0.9.4 in a clone of the https://github.com/buildbot/bbdocs/ repo
    • you may edit theThis is the Buildbot documentation for Buildbot version version manually in the index file (need to fix this problem)
    • run make in the bbdocs repo
    • commit and push to bbdocs. Ansible will automatically update the docs.buildbot.net site within an hour or so.
  • send mail to announce@… and users@…
    • sa2ajj: information in the mail?
  • Mark the milestone as complete in Trac and create a new one (for non-betas)
    • 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 Trac home page's news section with the new release
  • Update the #buildbot topic (for non-betas)
  • Build the tag on readthedocs.org
    • if this doesn't show up, double-check that the tag is on github
  • Merge back to master, updating the release date in the docs.

Beta Releases

Betas are much like "regular" releases, except that they are generally made from master, and do not get a release branch. When the "real" release is cut, generally the release notes from the betas are edited and combined into a single set of release notes, although the beta release notes are not deleted.

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 relnotes/index.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/relnotes/x.y.z.rst on master, and change the title and first sentence to reflect the most recent patch level.

Last modified 10 months ago Last modified on Feb 8, 2017, 1:52:50 PM