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)
- Tag in CVS, e.g, REL9_1_ALPHA1
- Export the CVS tag
- Release version number changes
- Build the actual release tarball: make distcheck
- Ask -hackers to check the tarball for sanity
- Upload to ftp server (under ~ftp on developer.postgresql.org)
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: 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.