38 lines
1.4 KiB
ReStructuredText
38 lines
1.4 KiB
ReStructuredText
===============
|
|
Release Process
|
|
===============
|
|
|
|
In order to allow for rapid, predictable releases, Setuptools uses a
|
|
mechanical technique for releases, enacted on tagged commits by
|
|
continuous integration.
|
|
|
|
To finalize a release, run ``tox -e finalize``, review, then push
|
|
the changes.
|
|
|
|
If tests pass, the release will be uploaded to PyPI.
|
|
|
|
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.
|