|
| 1 | +Some notes on PyMongo releases |
| 2 | +============================== |
| 3 | + |
| 4 | +Versioning |
| 5 | +---------- |
| 6 | + |
| 7 | +We shoot for a release every month or so - that will generally just |
| 8 | +increment the middle version number (e.g. 1.6.1 -> 1.7). We're |
| 9 | +getting to the point where a 2.0 release would be reasonable, though - |
| 10 | +a lot has changed since 1.0. |
| 11 | + |
| 12 | +Minor releases are reserved for bug fixes (in general no new features |
| 13 | +or deprecations) - they only happen in cases where there is a critical |
| 14 | +bug in a recently released version, or when a release has no new |
| 15 | +features or API changes. |
| 16 | + |
| 17 | +In between releases we use a "+" version number to denote the version |
| 18 | +under development. So if we just released 1.6, then the current dev |
| 19 | +version would be 1.6+. When we make the next release (1.6.1 or 1.7) we |
| 20 | +replace all instances of 1.6+ in the docs with the new version number. |
| 21 | + |
| 22 | +Deprecation |
| 23 | +----------- |
| 24 | + |
| 25 | +Changes should be backwards compatible unless absolutely |
| 26 | +necessary. When making API changes the approach is generally to add a |
| 27 | +deprecation warning but keeping the existing API |
| 28 | +functional. Eventually (after at least ~4 releases) we can remove the |
| 29 | +old API. |
| 30 | + |
| 31 | +Doing a Release |
| 32 | +--------------- |
| 33 | + |
| 34 | +1. Test release on Python 2.4-2.7 on Windows, Linux and OSX, with and |
| 35 | +without the C extension. Generally enough to just run the tests on 2.4 |
| 36 | +and 2.7 with and without the extension on a single platform, and then |
| 37 | +just test any version on the other platforms as a sanity check. |
| 38 | + |
| 39 | +2. Add release notes to doc/changelog.rst. Generally just |
| 40 | +summarize/clarify the git log, but might add some more long form notes |
| 41 | +for big changes. |
| 42 | + |
| 43 | +3. Search and replace the "+" version number w/ the new version number |
| 44 | +(see note above). |
| 45 | + |
| 46 | +4. Make sure version number is updated in setup.py and |
| 47 | +pymongo/__init__.py |
| 48 | + |
| 49 | +5. Commit with a BUMP version_number message. |
| 50 | + |
| 51 | +6. Tag w/ version_number |
| 52 | + |
| 53 | +7. Push commit / tag. |
| 54 | + |
| 55 | +8. Push source to PyPI: `python setup.py sdist upload` |
| 56 | + |
| 57 | +9. Push binaries to PyPI; for each version of python and platform do: |
| 58 | +`python setup.py bdist_egg upload`. Probably best to do `python |
| 59 | +setup.py bdist_egg` first, to make sure the egg builds |
| 60 | +properly. Notably on the Windows Python 2.5 machine you'll probably |
| 61 | +end up needing to do something like `python setup.py build -c mingw32 |
| 62 | +bdist_egg upload`. On Windows we also push a binary installer. The |
| 63 | +setup.py target for that is `bdist_wininst`. |
| 64 | + |
| 65 | +10. Make sure the docs have properly updated (driver buildbot does |
| 66 | +this). |
| 67 | + |
| 68 | +11. Add a "+" to the version number in setup.py/__init__.py, commit, |
| 69 | +push. |
| 70 | + |
| 71 | +12. Announce! |
0 commit comments