Skip to content

Commit ed5980b

Browse files
author
Mike Dirolf
committed
notes on doing a pymongo release
1 parent 1992b6c commit ed5980b

File tree

1 file changed

+71
-0
lines changed

1 file changed

+71
-0
lines changed

RELEASE.rst

Lines changed: 71 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,71 @@
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

Comments
 (0)