FM / python3-setuptools

/usr/share/doc/python3-setuptools

Name	Size	Mode	Actions
CHANGES.rst	113612	0644	edit dl rm
developer-guide.txt	5538	0644	edit dl rm
development.txt	1474	0644	edit dl rm
easy_install.txt	75343	0644	edit dl rm
formats.txt	31224	0644	edit dl rm
history.txt	1887	0644	edit dl rm
index.txt	537	0644	edit dl rm
pkg_resources.txt	93595	0644	edit dl rm
python3.txt	3964	0644	edit dl rm
README.rst	1545	0755	edit dl rm
releases.txt	2457	0644	edit dl rm
requirements.txt	61	0644	edit dl rm
roadmap.txt	167	0644	edit dl rm
setuptools.txt	128239	0644	edit dl rm

Edit: /usr/share/doc/python3-setuptools/releases.txt (2457B)

===============
Release Process
===============

In order to allow for rapid, predictable releases, Setuptools uses a
mechanical technique for releases, enacted by Travis following a
successful build of a tagged release per
`PyPI deployment <https://docs.travis-ci.com/user/deployment/pypi>`_.

Prior to cutting a release, please use `towncrier`_ to update
``CHANGES.rst`` to summarize the changes since the last release.
To update the changelog:

1. Install towncrier via ``pip install towncrier`` if not already installed.
2. Preview the new ``CHANGES.rst`` entry by running
   ``towncrier --draft --version {new.version.number}`` (enter the desired
   version number for the next release).  If any changes are needed, make
   them and generate a new preview until the output is acceptable.  Run
   ``git add`` for any modified files.
3. Run ``towncrier --version {new.version.number}`` to stage the changelog
   updates in git.

Once the changelog edits are staged and ready to commit, cut a release by
installing and running ``bump2version {part}`` where ``part``
is major, minor, or patch based on the scope of the changes in the
release. Then, push the commits to the master branch::

$ git push origin master
    $ git push --tags

If tests pass, the release will be uploaded to PyPI (from the Python 3.6
tests).

.. _towncrier: https://pypi.org/project/towncrier/

Release Frequency
-----------------

Some have asked why Setuptools is released so frequently. Because Setuptools
uses a mechanical release process, it's very easy to make releases whenever the
code is stable (tests are passing). As a result, the philosophy is to release
early and often.

While some find the frequent releases somewhat surprising, they only empower
the user. Although releases are made frequently, users can choose the frequency
at which they use those releases. If instead Setuptools contributions were only
released in batches, the user would be constrained to only use Setuptools when
those official releases were made. With frequent releases, the user can govern
exactly how often he wishes to update.

Frequent releases also then obviate the need for dev or beta releases in most
cases. Because releases are made early and often, bugs are discovered and
corrected quickly, in many cases before other users have yet to encounter them.

Release Managers
----------------

Additionally, anyone with push access to the master branch has access to cut
releases.

=============== Release Process =============== In order to allow for rapid, predictable releases, Setuptools uses a mechanical technique for releases, enacted by Travis following a successful build of a tagged release per `PyPI deployment `_. Prior to cutting a release, please use `towncrier`_ to update ``CHANGES.rst`` to summarize the changes since the last release. To update the changelog: 1. Install towncrier via ``pip install towncrier`` if not already installed. 2. Preview the new ``CHANGES.rst`` entry by running ``towncrier --draft --version {new.version.number}`` (enter the desired version number for the next release). If any changes are needed, make them and generate a new preview until the output is acceptable. Run ``git add`` for any modified files. 3. Run ``towncrier --version {new.version.number}`` to stage the changelog updates in git. Once the changelog edits are staged and ready to commit, cut a release by installing and running ``bump2version {part}`` where ``part`` is major, minor, or patch based on the scope of the changes in the release. Then, push the commits to the master branch:: $ git push origin master $ git push --tags If tests pass, the release will be uploaded to PyPI (from the Python 3.6 tests). .. _towncrier: https://pypi.org/project/towncrier/ Release Frequency ----------------- Some have asked why Setuptools is released so frequently. Because Setuptools uses a mechanical release process, it's very easy to make releases whenever the code is stable (tests are passing). As a result, the philosophy is to release early and often. While some find the frequent releases somewhat surprising, they only empower the user. Although releases are made frequently, users can choose the frequency at which they use those releases. If instead Setuptools contributions were only released in batches, the user would be constrained to only use Setuptools when those official releases were made. With frequent releases, the user can govern exactly how often he wishes to update. Frequent releases also then obviate the need for dev or beta releases in most cases. Because releases are made early and often, bugs are discovered and corrected quickly, in many cases before other users have yet to encounter them. Release Managers ---------------- Additionally, anyone with push access to the master branch has access to cut releases.