Alpha release process

From PostgreSQL wiki

Revision as of 10:31, 4 September 2010 by Petere (Talk | contribs)

Jump to: navigation, search



  • Commit fest manager declares commit fest closed
  • Build farm status is green, or failures are adequately explained (if widespread breakage, wait for a few days until fixed)


  • 8.5alpha1, 8.5alpha2, etc.

Release preparation

In general, src/tools/RELEASE_CHANGES applies. Exact procedure for alpha releases:

  1. Release notes [discussion]
  2. Optional: Update timezone data
  3. Optional: Translation updates (probably not useful for the first or second alpha)
  4. Tag in CVS, e.g, REL9_1_ALPHA1
  5. Export the CVS tag
  6. Release version number changes
  7. ./configure
  8. Build the actual release tarball: make distcheck
  9. Ask -hackers to check the tarball for sanity
  10. Upload to ftp server (under ~ftp on

Note: Per PGCon 2010 discussion, beginning with 9.1, we will no longer make a branch for each alpha release just to make the version number changes.

Note: It is very important not to introduce any stray files into the working tree created when you export the CVS tag. 'make distcheck' is not too smart and may incorporate such files into the release tarball.


Update web page:

Announce to:

  • PostgreSQL News
  • pgsql-announce

For this one, we don't wait for the binaries to be built before announcing. Just make sure that the source tarballs are in place before the announcements go out. This may take a day or three; doesn't really matter.

ReleasePrep contains notes about how to announce a release, which do not apply in their entirety to the alpha process, but are still worth digesting.

Personal tools