docs/releases.txt - platform/external/python/setuptools - Git at Google

 ===============
 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 check that the CHANGES.rst reflects
 the summary of changes since the last release.
 Ideally, these changelog entries would have been added
 along with the changes, but it's always good to check.
 Think about it from the
 perspective of a user not involved with the development--what would
 that person want to know about what has changed--or from the
 perspective of your future self wanting to know when a particular
 change landed.

 To cut a release, install and run ``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. If tests pass,
 the release will be uploaded to PyPI (from the Python 3.6 tests).

 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 <https://docs.travis-ci.com/user/deployment/pypi>`_.

	Prior to cutting a release, please check that the CHANGES.rst reflects
	the summary of changes since the last release.
	Ideally, these changelog entries would have been added
	along with the changes, but it's always good to check.
	Think about it from the
	perspective of a user not involved with the development--what would
	that person want to know about what has changed--or from the
	perspective of your future self wanting to know when a particular
	change landed.

	To cut a release, install and run ``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. If tests pass,
	the release will be uploaded to PyPI (from the Python 3.6 tests).

	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.