Chapter 11. Releasing a CDK version

Making a new CDK release involves much work. It is not just enough to build a set of CDK module jars from CVS and put that in a zip or tar file. Some quality has to be assured. This chapter will give an overview of the things that need to be done and checked before a release can be made.

Basically, the list below covers the process. In the rest of this chapter these points are further described.

  1. Make a clean CVS checkout (important!)

  2. Make the CDK in CVS compile from scratch

  3. Make the JUnit tests succeed (ant clean test-all), or report failing tests in the JavaDoc, using the @cdk.bug tag

  4. Remove @cdk.bug tags from JavaDoc which are now fixed, and possibly close the bugs on SourceForge

  5. Make the Javadoc generate (ant -f javadoc.xml html) without errors and warnings

  6. Check for PMD problems in the modules that are supposed to be released in a stable condition (ant -f pmd.xml pmd-data pmd-core pmd-XXX)

  7. Report bugs that cannot be fixed easily on SourceForge

  8. Determine the status of each module (stable, unstable)

  9. Make the Changelog up to date

  10. Make other documentation up to date

  11. Update the build.props file

  12. Make the source packages (ant sourcedist)

  13. Make the big jar (ant dist-large)

  14. Write the release notes

  15. Publish the packages on SourceForge

  16. Email the release notes to the mailling lists

  17. Update the website and add release notes to it. That is:

    Preferably, a large set of these things goes in a semi-automatic mechanism. Hence, my focus on the Plone FTP server!

  18. Tag CVS for this release (something like cvs tag cdk-200Y-MM-DD)

At this moment Christoph Steinbeck is CDK's release manager and takes care of all of this.