Fetching contributors…
Cannot retrieve contributors at this time
165 lines (104 sloc) 4.77 KB
Releasing Pyramid
- For clarity, we define releases as follows.
- Alpha, beta, dev and similar statuses do not qualify whether a release is
major or minor. The term "pre-release" means alpha, beta, or dev.
- A release is final when it is no longer pre-release.
- A *major* release is where the first number either before or after the
first dot increases. Examples: 1.6 to 1.7a1, or 1.8 to 2.0.
- A *minor* or *bug fix* release is where the number after the second dot
increases. Example: 1.6 to 1.6.1.
Prepare new release branch
- Create a new release branch, incrementing the version number.
- Do any necessary branch merges (e.g., master to branch, branch to master).
- On release branch:
$ git pull
- Do platform test via tox:
$ tox -r
Make sure statement coverage is at 100% (the test run will fail if not).
- Run tests on Windows if feasible.
- Make sure all scaffold tests pass (CPython 2.7, 3.4, 3.5, and 3.6, and PyPy
on UNIX; this doesn't work on Windows):
$ ./
- Ensure all features of the release are documented (audit CHANGES.txt or
communicate with contributors).
- Change CHANGES.txt heading to reflect the new version number.
- Copy relevant changes (delta bug fixes) from CHANGES.txt to
docs/whatsnew-X.X (if it's a major release). Minor releases should
include a link under "Bug Fix Releases" to the minor feature
changes in CHANGES.txt.
- Update README.rst to use correct versions of badges and URLs according to
each branch and context, i.e., RTD "latest" == GitHub/Travis "1.x-branch".
- Update whatsnew-X.X.rst in docs to point at change log entries for individual
releases if applicable.
- For major version releases, in, update branch descriptions.
- For major version releases, in docs/, update values under
html_theme_options for in_progress and outdated across master, releasing
branch, and previously released branch. Also in the previously released
branch only, uncomment the sections to enable pylons_sphinx_latesturl.
- Change version to the release version number.
- Make sure PyPI long description renders (requires ``readme`` installed
into your Python)::
$ python check -r -s -m
- Create a release tag.
- Make sure your Python has ``setuptools-git``, ``twine``, and ``wheel``
installed and release to PyPI::
$ python sdist bdist_wheel
$ twine upload dist/pyramid-X.X-*
- Configure RTD to publish the new release version of the docs.
Prepare master for further development (major releases only)
- Checkout master.
- In CHANGES.txt, preserve headings but clear out content. Add heading
"unreleased" for the version number.
- From the release branch, forward port the changes in CHANGES.txt to
- In, forward port branch descriptions from release branch.
- In docs/, add a commented line under
pylons_sphinx_latesturl_pagename_overrides for the release.
- Change version to the next version number.
Update previous version (final releases only)
- In docs/, update values under html_theme_options for in_progress and
outdated. Uncomment the sections to enable pylons_sphinx_latesturl.
- Configure RTD to point the "latest" alias to the new release version of the
Marketing and communications
- Edit Pylons/ for major releases,
pre-releases, and once pre-releases are final.
- Edit `
- Edit ` <>`_.
- Announce to Twitter.
Pyramid 1.x released.
=== One time only for new version, first pre-release ===
What's New
=== For all subsequent pre-releases ===
- Announce to maillist.
Pyramid 1.X.X has been released.
Here are the changes:
What's New In Pyramid 1.X:
1.X release documentation (across all alphas and betas, as well as when it gets
to final release):
You can install it via PyPI:
pip install Pyramid==1.X
Enjoy, and please report any issues you find to the issue tracker at
- Pyramid core developers