Version 27 (modified by jml, 7 years ago) (diff)


This document is a draft

How to do a pre-release

  1. File a ticket (e.g. #4290)
  2. Check buildbot to make sure all supported platforms are green (wait for pending builds if necessary).
  3. Make a branch (e.g. mkbranch Twisted release-4290)
  4. Run ./bin/admin/change-versions XX.YY.ZZpreN
  5. Commit the changes made by change-versions
  6. Run ./bin/admin/build-news .
  7. Commit the changes made by build-news
  8. Make a temporary directory for the tarballs to live in (e.g. mkdir /tmp/twisted-release)
  9. Run ./bin/admin/build-tarballs . /tmp/twisted-release/
  10. Upload the tarballs to a public website
  11. Announce the pre-release on
    1. the twisted-python mailing list
    2. on IRC in the #twisted topic
    3. in a blog post, ideally

Open questions

  • How do I decide the version number?
  • Do we need to commit the changes from build-news for pre-releases?
    • They leave the pre-release version in the NEWS files when doing pre-releases
    • But build-tarballs won't work with uncommitted changes
  • How do we manage the case where there are untested builds in trunk?
  • How/when in this process are the Windows installers and/or MacOS .dmg files created? See #3279.
    • (I presume .deb and .rpm packages are left up to Linux distro packagers)
  • How/when in this process are the docs built?
  • When should the front page of the wiki be updated?


  • Test change-versions with pre-releases
  • There should be a template for release announcements
    • Pre-release announcements should include an exhortation to test
    • Release announcements should include actual NEWS summaries and maybe a pointer to the full thing
  • There are missing scripts:
    • for uploading pre-release tarballs
      • Need a standard place to upload tarballs
    • for signing tarballs
    • for uploading release tarballs
  • It would be nice if the news fragments contained information about who made the changes

Suggestions for additions to pre-release steps

  • pick a release quote :)
  • bump copyrights in [source:trunk/LICENSE], [source:trunk/twisted/] and [source:trunk/README]
  • Delete the news NNNN.bugfix etc files after building [source:trunk/NEWS]
  • Check the milestone for the upcoming release, get rid of any non-critical bugs
  • Check for any open tickets marked regressions, get them fixed
  • A thought for future releases: since we'd really like folks to download the prereleases and try them out, perhaps we should put the [source:trunk/NEWS NEWS] file on the web somewhere official, too, so they can see all the cool stuff they can try out?
    • "Other fixes" and maybe all tickets should be links when they are on the web
  • Document how and when to tag releases in SVN.
  • Read through the NEWS files and write a summary of the interesting changes for the release
  • Read the INSTALL file, check the required Python version. If it mentions supported platforms, check that the list matches the current set of buildbots.
  • Get cube access

For the release itself

  • Remove the 'pre'
    • So tedious! Write a tool to do this.
    • XXX: File a bug
    • find . -type f -not -path '*.svn*' -not -name '*~' | xargs grep -n 'pre2'
  • Add the quote of the release
  • Make new tarballs
  • Upload to the official upload locations:
    • Prerequisites: cube account; write access to /srv/www-data/twisted/Releases/
    • <radix> jml: cube:/srv/www-data/twisted/Releases/<Project>/<First two parts of version number>/*
    • We hell of need a script to do this too. XXX: file a bug
  • Announce more fully:
    • python-announce
    • PyPI
    • Launchpad
    • twisted-python
    • twisted-web
  • Packaging
    • Do we need to do anything for Debian / Ubuntu?
    • OS X
      • Packaging not necessary, there's no good way to make an installer that overrides the default Python see #3279
      • Definitely need instructions for OS X-using developers who want to use a more recent version of Twisted
    • Win32 - see [source:trunk/win32/maintainer-notes.txt]
    • eggs?