root/tags/0.4.1/RELEASE.howto

Revision 118, 3.8 kB (checked in by lgs, 3 years ago)

Bump version number and prepare next release

Line 
1This is taken from:
2
3http://svn.zope.org/*checkout*/Sandbox/philikon/foundation/releasing-software.txt
4
5Releasing software
6------------------
7
8When releasing software, the following steps should be taken:
9
101. Make sure all automated tests of the package pass.
11
122. Fill in the release date in ``CHANGES.txt``.  Make sure the
13   changelog is complete.
14
153. Make sure the package metadata in ``setup.py`` is up-to-date.  You
16   can verify the information by re-generating the egg info::
17
18     python setup.py egg_info
19
20   and inspecting ``src/EGGNAME.egg-info/PKG-INFO``.  You should also
21   make sure the that the long description renders as valid
22   reStructuredText.  You can do this by using the ``rst2html.py``
23   utility from docutils_::
24
25     python setup.py --long-description | rst2html.py > test.html
26
27   If this will produce warnings or errors, PyPI will be unable to
28   render the long description nicely.  It will treat it as plain text
29   instead.
30
314. Create a release tag:
32
33   svn copy http://www.lorenzogil.com/svn/pycha/trunk \
34            http://www.lorenzogil.com/svn/pycha/tags/X.Y.Z
35
365. Get a separate checkout of the release tag for creating the
37   distribution tarball and eggs.  It is important that you don't do
38   this on the trunk or release branch to avoid
39
40   - forgetting to tag the release at all.
41
42   - forgetting to clean up the ``build`` directory that distutils and
43     setuptools create. Failure to do so may result in old artefacts
44     in eggs.
45
46   - forgetting to check in files that are needed by ``setup.py`` or
47     as package data.  Setuptools will only include them in the
48     distribution if they are checked into subversion.
49
50   In the checkout of the tag perform the following steps:
51
52   a) Remove the "dev" marker from the version in ``setup.py``
53
54   b) Commit these changes.  It's acceptable that these changes modify
55      the tag since they're purely related to release management.
56
57   c) Create a distribution and upload it to PyPI using the following
58      command::
59
60        python setup.py register sdist upload
61
62      If the package contains C extensions, you need to upload a
63      binary Windows egg as well::
64
65        python setup.py bdist_egg upload
66
67      This may require the help from someone with a Windows
68      installation and proper tools (Visual C).
69
70      Binary eggs for Linux or MacOSX should **never** be uploaded
71      because those platforms vary too much to be binary-compatible
72      with each other, due to varying UCS support, different libc
73      versions and linking models (framework / non-framework).
74
756. Back on the trunk or the release branch, increase the version
76   number in ``setup.py`` to the *next* release while preserving the
77   ``dev`` marker.  The convention is that the trunk or release branch
78   always points to the upcoming release, *not* the one that has been
79   released already.  So if you've just released version 3.4.1, you
80   should change ``setup.py`` to read::
81
82     setup(
83         name='...',
84         version='3.4.2dev',
85         ...
86         )
87
88   In ``CHANGES.txt`` add a *new* section for the upcoming release.
89   The release date for that should say "unreleased" so that
90   committers recording their changes won't accidentally put their
91   entry in the section for an already released version.  For
92   example::
93
94     3.4.2 (unreleased)
95     ------------------
96
97     * ...
98
99     3.4.1 (2007-01-24)
100     ------------------
101
102     * Fixed bug in the foo adapter.
103
104     * Added a bar utility for optimized kaboodling.
105
106     3.4.0 (2006-09-13)
107     ------------------
108
109     Initial release as separate egg.
110
111**Important:** Once released to PyPI or any other public download
112location, a released egg may *never* be removed, even if it has proven
113to be a faulty release ("brown bag release").  In such a case it
114should simply be superseded immediately by a new, improved release.
115
116.. _docutils: http://docutils.sourceforge.net/
Note: See TracBrowser for help on using the browser.