You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
49 lines
2.1 KiB
49 lines
2.1 KiB
7 months ago
|
===============
|
||
|
|
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.
|