-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathRELEASE.howto
101 lines (69 loc) · 3.18 KB
/
RELEASE.howto
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
This is taken from:
http://svn.zope.org/*checkout*/Sandbox/philikon/foundation/releasing-software.txt
Releasing software
------------------
When releasing software, the following steps should be taken:
1. Make sure all automated tests of the package pass.
2. Fill in the release date in ``CHANGES.txt``. Make sure the
changelog is complete. Commit this change.
3. Make sure the package metadata in ``setup.py`` is up-to-date. You
can verify the information by re-generating the egg info::
python setup.py egg_info
and inspecting ``pycha.egg-info/PKG-INFO``. You should also
make sure the that the long description renders as valid
reStructuredText. You can do this by using the ``rst2html.py``
utility from docutils_::
python setup.py --long-description | rst2html > test.html
If this will produce warnings or errors, PyPI will be unable to
render the long description nicely. It will treat it as plain text
instead.
4. Remove the "dev" marker from the ``setup.py`` or the file where
setup.py reads it (e.g. pycha/__init__.py). Also change the
documentation version. Commit these changes.
5. Create a release tag:
hg tag X.Y.Z
6. Create a distribution and upload it to PyPI using the following
command::
python setup.py register sdist upload
If the package contains C extensions, you need to upload a
binary Windows egg as well::
python setup.py bdist_egg upload
This may require the help from someone with a Windows
installation and proper tools (Visual C).
Binary eggs for Linux or MacOSX should **never** be uploaded
because those platforms vary too much to be binary-compatible
with each other, due to varying UCS support, different libc
versions and linking models (framework / non-framework).
7. Increase the version number in ``setup.py`` to the *next*
release while preserving the ``dev`` marker. The convention
is that the trunk or release branch always points to the
upcoming release, *not* the one that has been released already.
So if you've just released version 3.4.1, you should change
``setup.py`` to read::
setup(
name='...',
version='3.4.2dev',
...
)
In ``CHANGES.txt`` add a *new* section for the upcoming release.
The release date for that should say "unreleased" so that
committers recording their changes won't accidentally put their
entry in the section for an already released version. For
example::
3.4.2 (unreleased)
------------------
* ...
3.4.1 (2007-01-24)
------------------
* Fixed bug in the foo adapter.
* Added a bar utility for optimized kaboodling.
3.4.0 (2006-09-13)
------------------
Initial release as separate egg.
8. If this is a non bug fix release, write the release notes and upload
them to http://pypi.python.org/pypi?%3Aaction=pkg_edit&name=pycha
**Important:** Once released to PyPI or any other public download
location, a released egg may *never* be removed, even if it has proven
to be a faulty release ("brown bag release"). In such a case it
should simply be superseded immediately by a new, improved release.
.. _docutils: http://docutils.sourceforge.net/