|Version 3 (modified by radix, 8 years ago) (diff)|
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.
- Automate the updating of version numbers in the code for an upcoming release.
- Automate documentation generation in a way suitable for inclusion in release tarballs.
- Automate man-page web page generation suitable for inclusion in release tarballs.
- Automate generation of release tarballs
- Automate generation of the NEWS file
The rest is about publishing the release and its documentation.
- Automate generation of "the book"
- Automate publishing of "howto" documents to the web site
- Automate updating the API documentation on the web site
- Automate updating the "downloads" page with references to the latest release
- 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:
- Create a tool for doing all of the previous items; that is, it will update version numbers, generate all documentation, help you build a NEWS file, create a tarball from the result of those items, and then publish the release to the web site (including publishing the documentation) and upload it to mirrors.
- 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.