wiki:ReleaseProcess

Version 45 (modified by jml, 5 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. Read through the INSTALL and README files to make sure things like the supported Python versions are correct
  4. Make a branch (e.g. mkbranch Twisted release-4290)
  5. Run ./bin/admin/change-versions XX.YY.ZZpreN
  6. Commit the changes made by change-versions
  7. Run ./bin/admin/build-news .
  8. Commit the changes made by build-news
  9. Make a temporary directory for the tarballs to live in (e.g. mkdir /tmp/twisted-release)
  10. Run ./bin/admin/build-tarballs . /tmp/twisted-release/
  11. Upload the tarballs to a public website
  12. Announce the pre-release on
    1. the twisted-python mailing list
    2. on IRC in the #twisted topic
    3. in a blog post, ideally labs.twistedmatrix.com

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?

Notes

  • 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
  • Mine ReleaseProcedure for useful information

Suggestions for additions to pre-release steps

  • pick a release quote :)
  • bump copyrights in trunk/LICENSE, trunk/twisted/_version.py and trunk/README
  • Delete the news NNNN.bugfix etc files after building 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 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

Some helpful sanity checks

  • Read through the INSTALL and README files to make sure things like the supported Python versions are correct