Skip to content
Fetching contributors…
Cannot retrieve contributors at this time
67 lines (43 sloc) 3.33 KB

Some notes on PyMongo releases


We shoot for a release every month or so - that will generally just increment the middle version number (e.g. 1.6.1 -> 1.7). We're getting to the point where a 2.0 release would be reasonable, though - a lot has changed since 1.0.

Minor releases are reserved for bug fixes (in general no new features or deprecations) - they only happen in cases where there is a critical bug in a recently released version, or when a release has no new features or API changes.

In between releases we use a "+" version number to denote the version under development. So if we just released 1.6, then the current dev version would be 1.6+. When we make the next release (1.6.1 or 1.7) we replace all instances of 1.6+ in the docs with the new version number.


Changes should be backwards compatible unless absolutely necessary. When making API changes the approach is generally to add a deprecation warning but keeping the existing API functional. Eventually (after at least ~4 releases) we can remove the old API.

Doing a Release

  1. Test release on Python 2.4-2.7 on Windows, Linux and OSX, with and without the C extension. Generally enough to just run the tests on 2.4 and 2.7 with and without the extension on a single platform, and then just test any version on the other platforms as a sanity check. python test will build the extension and test. python tools/ will remove the extension, and then nosetests will run the tests without it. Can also run the doctests: python doc -t. For building extensions on Windows check section below.
  2. Add release notes to doc/changelog.rst. Generally just summarize/clarify the git log, but might add some more long form notes for big changes.
  3. Search and replace the "+" version number w/ the new version number (see note above).
  4. Make sure version number is updated in and pymongo/
  5. Commit with a BUMP version_number message.
  6. Tag w/ version_number
  7. Push commit / tag.
  8. Push source to PyPI: python sdist upload
  9. Push binaries to PyPI; for each version of python and platform do: python bdist_egg upload. Probably best to do python bdist_egg first, to make sure the egg builds properly. Notably on the Windows machine, for Python 2.4 and 2.5, you will have to run python build -c mingw32 bdist_egg upload or the C extension build will fail with an error about Visual Studio 2003. On Windows we also push a binary installer. The target for that is bdist_wininst.
  10. Make sure the docs have properly updated (driver buildbot does this).
  11. Add a "+" to the version number in, commit, push.
  12. Announce!

Building extensions on Windows

Currently the default python test builds extensions on Windows 32 bit only. The default option expects Visual Studio 2008. This has been tested with Python 2.6 and 2.7. The extensions can be built for Python 2.4 and 2.5 using MinGW32 (See Doing a Release above).

  1. On your Windows 32 bit machine install Microsoft Visual C++ 2008 Express Edition (or equivalent 2008 edition) in the default location.
  2. Ensure you have nose installed.
  3. Run python test to build the C extensions and run pymongo tests.
Something went wrong with that request. Please try again.