wiki:ReleaseAutomation

Version 6 (modified by exarkun, 6 years ago) (diff)

some more detail about the wholistic tool

Release Automation

Tickets related to this spec are in the Twisted 8.0 milestone.

Here's what we need to do, vaguely in order of dependency, with test-driven development.

The first group of things is related to actually creating a package of Twisted itself that we can release.

The rest is about publishing the release and its documentation.

The tasks related to publishing things to the web site should ensure that compatibility with current forms and URLs is maintained. The "WebSite" svn repo contains our web site configuration, which will probably require some changes. It doesn't matter if the publishing stuff is "push", i.e. uploading some files to a web server, or "on-demand", by having dynamic code running on the server that automatically finds the latest release. It just needs to be tested!

And to bring all of the previous items together:

  • Create a tool for doing all of the previous items. It will:
    • create a new branch from trunk. Operating on the branch:
      • update version numbers
      • help you build a NEWS file
      • commit changes
    • create a release tag of the branch
    • merge the branch into trunk
    • export the release tag. Operating on the export:
      • generate all documentation
        • howtos
        • API docs
      • create tarballs from the result of those items
        • one for each project
        • one for everything
    • publish the release to the web site (including publishing the documentation)
      • upload the source tarballs such that they can be downloaded from the website
      • modify the website to refer to the new release
      • upload the documentation and modify website to refer to it
    • upload tarballs to mirrors.

In addition,

This should give a pretty clear idea of what needs to be done. If anything's unclear, then you should assume that the behavior is yet to be defined, and try to help define it. Just make sure everything "public" is backwards compatible. These tickets are largely defined in terms of requirements, and implementation is irrelevant as long as it is high-quality code.