= Release Automation =

Tickets related to this spec are in the [milestone:twisted-8.0 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.

 * [ticket:2885 Automate the updating of version numbers] in the code for an upcoming release.
 * [ticket:3040 Set version information in new deprecations to the version number actually associated with a release]
 * [ticket:2925 Automate documentation generation] in a way suitable for inclusion in release tarballs.
 * [ticket:2940 Automate man-page web page generation] suitable for inclusion in release tarballs.
 * [ticket:2886 Automate generation of release tarballs]
 * [ticket:2884 Automate generation of the NEWS file]

The rest is about publishing the release and its documentation.

 * [ticket:2941 Automate generation of "the book"]
 * [ticket:2890 Automate publishing of "howto" documents to the web site]
 * [ticket:2891 Automate updating the API documentation on the web site]
 * [ticket:2889 Automate updating the "downloads" page with references to the latest release]
 * [ticket:2888 Automate uploading of the released tarballs to our file distribution mirrors]

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:

 * [ticket:2892 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.
    * [ticket:3439 Create a tool for creating an "upstream package" from the export]:
      * generate all documentation
        * for the website (including links in the generated output which may refer to the website)
          * howtos
          * [ticket:3069 API docs]
          * PDF book
        * for the tarballs (including links in the generated output which may not refer to the website)
          * howtos
      * 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, 

 * [ticket:2308 We should have a buildbot which runs the automated package-building and installs it and runs the tests from that installed version].

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.