[Checkins] SVN: Sandbox/philikon/foundation/ Move "Releasing
software" section out to separate file, per Jim's request.
Philipp von Weitershausen
philikon at philikon.de
Wed Oct 3 15:22:36 EDT 2007
Log message for revision 80560:
Move "Releasing software" section out to separate file, per Jim's request.
Changed:
U Sandbox/philikon/foundation/maintaining-software.txt
A Sandbox/philikon/foundation/releasing-software.txt
-=-
Modified: Sandbox/philikon/foundation/maintaining-software.txt
===================================================================
--- Sandbox/philikon/foundation/maintaining-software.txt 2007-10-03 18:55:52 UTC (rev 80559)
+++ Sandbox/philikon/foundation/maintaining-software.txt 2007-10-03 19:22:36 UTC (rev 80560)
@@ -403,87 +403,8 @@
.. _Trove classifiers: http://pypi.python.org/pypi?%3Aaction=list_classifiers
-Releasing software
-------------------
+.. include:: releasing-software.txt
-When releasing software, the following steps should be taken:
-
-1. Make sure all automated tests of the package pass.
-
-2. Update the changelog to note the release date. Make sure the
- changelog is complete.
-
-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 ``src/EGGNAME.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.py > 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. Create a release tag.
-
-5. Get a separate checkout of the release tag for creating the
- distribution tarball and eggs. It is important that you don't do
- this on the trunk or release branch to avoid
-
- - forgetting to tag the release at all.
-
- - forgetting to clean up the ``build`` directory that distutils and
- setuptools create. Failure to do so may result in old artefacts
- in eggs.
-
- - forgetting to check in files that are needed by ``setup.py`` or
- as package data. Setuptools will only include them in the
- distribution if they are checked into subversion.
-
-6. From the tag checkout, upload the package to PyPI with the following
- command::
-
- python setup.py register sdist upload
-
- If the package contains C extensions and you have access to a
- Windows machine with a Visual C compiler installed, you should
- consider uploading a binary Windows egg as well::
-
- python setup.py bdist_egg upload
-
- Binary eggs for Linux or MacOSX should *not* be uploaded because
- those platforms vary too much to be binary-compatible with each
- other, due to various libc versions and linking models (framework /
- non-framework).
-
-7. Increase the version number (in ``setup.py`` and elsewhere) on the
- trunk or the release branch to the *next* release. The convention
- is that the trunk or release branch always points to the upcoming
- release, *not* the one that has been released already.
-
- Add a new section to the changelog for the upcoming release called
- with a release date "unreleased" so that committers recording their
- changes won't accidentally put their entry in the section for an
- already released version. For example::
-
- 1.1 (unreleased)
- ----------------
-
- * ...
-
- 1.0 (2007-01-24)
- ----------------
-
- Initial release
-
-
-.. _docutils: http://docutils.sourceforge.net/
-
Missing subjects
----------------
Copied: Sandbox/philikon/foundation/releasing-software.txt (from rev 80515, Sandbox/philikon/foundation/maintaining-software.txt)
===================================================================
--- Sandbox/philikon/foundation/releasing-software.txt (rev 0)
+++ Sandbox/philikon/foundation/releasing-software.txt 2007-10-03 19:22:36 UTC (rev 80560)
@@ -0,0 +1,80 @@
+Releasing software
+------------------
+
+When releasing software, the following steps should be taken:
+
+1. Make sure all automated tests of the package pass.
+
+2. Update the changelog to note the release date. Make sure the
+ changelog is complete.
+
+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 ``src/EGGNAME.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.py > 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. Create a release tag.
+
+5. Get a separate checkout of the release tag for creating the
+ distribution tarball and eggs. It is important that you don't do
+ this on the trunk or release branch to avoid
+
+ - forgetting to tag the release at all.
+
+ - forgetting to clean up the ``build`` directory that distutils and
+ setuptools create. Failure to do so may result in old artefacts
+ in eggs.
+
+ - forgetting to check in files that are needed by ``setup.py`` or
+ as package data. Setuptools will only include them in the
+ distribution if they are checked into subversion.
+
+6. From the tag checkout, upload the package to PyPI with the following
+ command::
+
+ python setup.py register sdist upload
+
+ If the package contains C extensions and you have access to a
+ Windows machine with a Visual C compiler installed, you should
+ consider uploading a binary Windows egg as well::
+
+ python setup.py bdist_egg upload
+
+ Binary eggs for Linux or MacOSX should *not* be uploaded because
+ those platforms vary too much to be binary-compatible with each
+ other, due to various libc versions and linking models (framework /
+ non-framework).
+
+7. Increase the version number (in ``setup.py`` and elsewhere) on the
+ trunk or the release branch to the *next* release. The convention
+ is that the trunk or release branch always points to the upcoming
+ release, *not* the one that has been released already.
+
+ Add a new section to the changelog for the upcoming release called
+ with a release date "unreleased" so that committers recording their
+ changes won't accidentally put their entry in the section for an
+ already released version. For example::
+
+ 1.1 (unreleased)
+ ----------------
+
+ * ...
+
+ 1.0 (2007-01-24)
+ ----------------
+
+ Initial release
+
+
+.. _docutils: http://docutils.sourceforge.net/
More information about the Checkins
mailing list