| 1 | This is taken from: |
|---|
| 2 | |
|---|
| 3 | http://svn.zope.org/*checkout*/Sandbox/philikon/foundation/releasing-software.txt |
|---|
| 4 | |
|---|
| 5 | Releasing software |
|---|
| 6 | ------------------ |
|---|
| 7 | |
|---|
| 8 | When releasing software, the following steps should be taken: |
|---|
| 9 | |
|---|
| 10 | 1. Make sure all automated tests of the package pass. |
|---|
| 11 | |
|---|
| 12 | 2. Fill in the release date in ``CHANGES.txt``. Make sure the |
|---|
| 13 | changelog is complete. |
|---|
| 14 | |
|---|
| 15 | 3. 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 | |
|---|
| 31 | 4. 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 | |
|---|
| 36 | 5. 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 | |
|---|
| 75 | 6. 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 |
|---|
| 112 | location, a released egg may *never* be removed, even if it has proven |
|---|
| 113 | to be a faulty release ("brown bag release"). In such a case it |
|---|
| 114 | should simply be superseded immediately by a new, improved release. |
|---|
| 115 | |
|---|
| 116 | .. _docutils: http://docutils.sourceforge.net/ |
|---|