Release Checklist

Before a new release

• Send a headsup to pandas-dev at least a few days beforehand to give all insterested parties time to raise issues.
• Make sure whatsnew and release.rst are synchronized and cover the changes made during the release cycle.
• clear the bug queue, move everything which will not be part of the release to a new milestone.
• Make sure the builds are green across all platforms we monitor: linux, windows, sparc (debian), and freebsd. Although the latter platforms have a small user base, they're invaluable in flagging incorrect assumptions made in code.
• Prior to a final release an RC should have been released and announced, followed by a suitable period (min. two weeks) for bug reports to come in. Once the bug rate drops off, release the next RC or ship the final.
• Once the first RC is released, a feature-freeze is in effect until the final is released, bug fixes and harmless cleanups only.

When releasing:

• In setup.py update the version strings as needed and set ISRELEASED.
• tag the commit using an annotated tag. follow established pattern for tags. Rememeber to push the tag along with the commit. Make sure you don't push unintended tags.
• Follow the release commit immediately with a commit that sets ISRELEASED=False, and bump the version if required (Following established practice, which may change).
• Follow up to make sure binaries are made available, and an ANN is sent to the mailing list.

After a release

• Immediately after a final release a cooldown period (min. two weeks) is in effect, giving the users who didn't respond to the RC call-to-test time to report show-stopper bugs.
• If during the cooldown period major regressions are reported, prepare for a 0.x.1 release. This ensures that a stable version is available to users during the next release cycle. send a mail to pandas-dev to update all contributors.
• Once the cool down period is over, start merging PRs pending for the new cycle.