You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: RELEASE.rst
+10-22Lines changed: 10 additions & 22 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,34 +4,31 @@ Some notes on PyMongo releases
4
4
Versioning
5
5
----------
6
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.
7
+
We shoot for a release every few months - that will generally just
8
+
increment the middle version number (e.g. 2.1.1 -> 2.2).
11
9
12
10
Minor releases are reserved for bug fixes (in general no new features
13
11
or deprecations) - they only happen in cases where there is a critical
14
12
bug in a recently released version, or when a release has no new
15
13
features or API changes.
16
14
17
15
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.
16
+
under development. So if we just released 2.1, then the current dev
17
+
version would be 2.1+. When we make the next release (2.1.1 or 2.2) we
18
+
replace all instances of 2.1+ in the docs with the new version number.
21
19
22
20
Deprecation
23
21
-----------
24
22
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.
23
+
Changes should be backwards compatible unless absolutely necessary. When making
24
+
API changes the approach is generally to add a deprecation warning but keeping
25
+
the existing API functional. Eventually (after at least ~4 releases) we can
26
+
remove the old API.
30
27
31
28
Doing a Release
32
29
---------------
33
30
34
-
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 setup.py test` will build the extension and test. `python tools/clean.py` will remove the extension, and then `nosetests` will run the tests without it. Can also run the doctests: `python setup.py doc -t`. For building extensions on Windows check section below.
31
+
1. Test release on Python 2.4-2.7 and 3.1-3.2 on Windows, Linux and OSX, with and without the C extension. Generally enough to just run the tests on 2.4, 2.7 and 3.2 with and without the extension on a single platform, and then just test any version on the other platforms as a sanity check. `python setup.py test` will build the extension and test. `python tools/clean.py` will remove the extension, and then `nosetests` will run the tests without it. Can also run the doctests: `python setup.py doc -t`. For building extensions on Windows check section below.
35
32
36
33
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.
37
34
@@ -55,12 +52,3 @@ Doing a Release
55
52
56
53
12. Announce!
57
54
58
-
Building extensions on Windows
59
-
------------------------------
60
-
Currently the default `python setup.py test` builds extensions on Windows 32 bit only. The default option requires Visual Studio (C++ Express) 2008 and works with Python 2.6 and 2.7. The tests can be run in Python 2.4 and 2.5 by installing MingW32 and running the appropriate command in step 3 below.
61
-
62
-
1. On your Windows 32 bit machine install Microsoft Visual C++ 2008 Express Edition (or equivalent 2008 edition) in the default location. For Python 2.4 or 2.5 install MingW32 in it's default location.
63
-
64
-
2. Ensure you have nose installed.
65
-
66
-
3. Run `\path\to\Python2(6|7) setup.py test` or `\path\to\Python2(4|5) setup.py build -c mingw32 test` to build the C extensions and run pymongo tests.
0 commit comments