Scripting Svn Releases

The Subversion release process had too many manual steps in it.

The manual effort required was becoming a burden, now we’re doing a “regular” release every six months, as well as a source of inconsistency and errors.

As part of an effort to improve stability and availability of Subversion releases, I’m scripting some of the manual steps to bring us closer to automated releases.

The headings below link to the descriptions in our community guide. An automated step or set of steps is indicated as “release.py <command>“; the rest are manual. Steps in strikethrough were previously manual, now automated.

Creating a new minor release branch

• release.py create-release-branch
  • Create the new release branch with a server-side copy
  • increment version in svn_version.h, NativeResources.java, main.py
  • add a section in CHANGES
  • Create a new STATUS file on the release branch
  • add the new branch to the buildbot config
• release.py write-release-notes
  • Create a template release-notes document
  • Commit it
• Ask someone with appropriate access to add the A.B.x branch to the backport merge bot.

Rolling a release (repeat for both RC and final release)

• Merge CHANGES file from trunk to release branch; set the release date in it.
• Check get-deps.sh works on the release branch.
• release.py roll
• Test one or both of the tarballs
• release.py sign-candidates
• release.py create-tag
• release.py post-candidates
• send an email to the dev@ list
• adjust the topic on #svn-dev to mention “X.Y.Z is up for testing/signing”
• Update the issue tracker to have appropriate versions/milestones

The actual releasing (repeat for both RC and final release)

• Uploading the release
  • release.py move-to-dist
  • wait 24 hours
  • release.py clean-dist
  • Submit the new release version number on reporter.apache.org
• Announcing the release
  • release.py write-announcement
    • send the announcement email
  • Update the topics in IRC channels #svn, #svn-dev
• Update the website, any release:
  • release.py write-downloads
    • edit the result in download.html
  • release.py write-news … news.html
    
  • release.py write-news … index.html
    • check date, text, URL; remove old news from index.html
• Update the website, stable release X.Y.Z (not alpha/beta/rc):
  • List the new release in doap.rdf
  • List the new release in release-history.html
• Update the website, new minor release X.Y.0:
  • Update the support levels in release-notes/index.html
  • Update supported_release_lines in release.py
  • Remove “draft” warning from release-notes/X.Y.html
  • Create/update API docs: docs/api/X.Y, docs/javahl/X.Y
    • an example script is given in the doc
    • Update the links to the API docs in docs/index.html
  • Publish (commit or merge) these modifications

So quite a bit still to do…