Alpha release process
From PostgreSQL wiki
- 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.
In general, src/tools/RELEASE_CHANGES applies. Exact procedure for alpha releases:
- Release notes [discussion]
- Optional: Update timezone data
- Optional: Translation updates (probably not useful for the first or second alpha)
- Note down the SHA1 of the head commit, don't tag yet.
- Export the tree, e.g.: mkdir ../export; git archive SHA1 | tar -C ../export -x -f -; cd ../export (Steps from here on should be done on developer.postgresql.org, so we get for example a consistent flex version.)
- Release version number changes, e.g,.: src/tools/version_stamp.pl alpha2; autoconf
- Build the actual release tarball: make distcheck
- Create md5 sum files: md5 filename > filename.md5
- Ask -hackers to check the tarball for sanity
- Upload to ftp server (under ~ftp on developer.postgresql.org)
- When the release is final, tag the SHA1: git tag REL9_1_ALPHA2; and push the tag.
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 Git tree. 'make distcheck' is not too smart and may incorporate such files into the release tarball.
Update web page: http://www.postgresql.org/developer/alpha
- PostgreSQL News
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.