From 6a0e8490678271977076fb1cd155e57ec641b4d6 Mon Sep 17 00:00:00 2001 From: Bruno Oliveira Date: Fri, 19 Aug 2016 18:50:46 -0300 Subject: [PATCH] Update HOWTORELEASE based on the 3.0.0 release --- HOWTORELEASE.rst | 111 ++++++++++++++++++++++------------------------- tox.ini | 2 +- 2 files changed, 53 insertions(+), 60 deletions(-) diff --git a/HOWTORELEASE.rst b/HOWTORELEASE.rst index afc0c3bc3..e6f1973b6 100644 --- a/HOWTORELEASE.rst +++ b/HOWTORELEASE.rst @@ -3,90 +3,83 @@ How to release pytest Note: this assumes you have already registered on pypi. -0. create the branch release-VERSION - use features as base for minor/major releases - and master as base for bugfix releases +1. Bump version numbers in ``_pytest/__init__.py`` (``setup.py`` reads it). -1. Bump version numbers in _pytest/__init__.py (setup.py reads it) +2. Check and finalize ``CHANGELOG.rst``. -2. Check and finalize CHANGELOG +3. Write ``doc/en/announce/release-VERSION.txt`` and include + it in ``doc/en/announce/index.txt``. Run this command to list names of authors involved:: -3. Write doc/en/announce/release-VERSION.txt and include - it in doc/en/announce/index.txt:: + git log $(git describe --abbrev=0 --tags)..HEAD --format='%aN' | sort -u - git log 2.8.2..HEAD --format='%aN' | sort -u # lists the names of authors involved +4. Regenerate the docs examples using tox:: -4. Use devpi for uploading a release tarball to a staging area:: + tox -e regen + +5. At this point, open a PR named ``release-X`` so others can help find regressions or provide suggestions. + +6. Use devpi for uploading a release tarball to a staging area:: devpi use https://devpi.net/USER/dev devpi upload --formats sdist,bdist_wheel -5. Run from multiple machines:: +7. Run from multiple machines:: devpi use https://devpi.net/USER/dev devpi test pytest==VERSION -6. Check that tests pass for relevant combinations with:: + Alternatively, you can use `devpi-cloud-tester `_ to test + the package on AppVeyor and Travis (follow instructions on the ``README``). + +8. Check that tests pass for relevant combinations with:: devpi list pytest or look at failures with "devpi list -f pytest". -7. Regenerate the docs examples using tox, and check for regressions:: - - tox -e regen - git diff - - -8. Build the docs, you need a virtualenv with py and sphinx - installed:: - - cd doc/en - make html - - Commit any changes before tagging the release. - -9. Tag the release:: - - git tag VERSION - git push - -10. Upload the docs using doc/en/Makefile:: - - cd doc/en - make install # or "installall" if you have LaTeX installed for PDF - - This requires ssh-login permission on pytest.org because it uses - rsync. - Note that the ``install`` target of ``doc/en/Makefile`` defines where the - rsync goes to, typically to the "latest" section of pytest.org. - - If you are making a minor release (e.g. 5.4), you also need to manually - create a symlink for "latest":: - - ssh pytest-dev@pytest.org - ln -s 5.4 latest - - Browse to pytest.org to verify. - -11. Publish to pypi:: +9. Feeling confident? Publish to pypi:: devpi push pytest==VERSION pypi:NAME - where NAME is the name of pypi.python.org as configured in your ``~/.pypirc`` - file `for devpi `_. + where NAME is the name of pypi.python.org as configured in your ``~/.pypirc`` + file `for devpi `_. +10. Tag the release:: -12. Send release announcement to mailing lists: + git tag VERSION + git push origin VERSION - - pytest-dev - - testing-in-python + Make sure ```` is **exactly** the git hash at the time the package was created. + +11. Send release announcement to mailing lists: + + - pytest-dev@python.org + - testing-in-python@lists.idyll.org - python-announce-list@python.org + And announce the release on Twitter, making sure to add the hashtag ``#pytest``. + +12. **After the release** + + a. **patch release (2.8.3)**: + + 1. Checkout ``master``. + 2. Update version number in ``_pytest/__init__.py`` to ``"2.8.4.dev"``. + 3. Create a new section in ``CHANGELOG.rst`` titled ``2.8.4.dev`` and add a few bullet points as placeholders for new entries. + 4. Commit and push. + + b. **minor release (2.9.0)**: + + 1. Merge ``features`` into ``master``. + 2. Checkout ``master``. + 3. Follow the same steps for a **patch release** above, using the next patch release: ``2.9.1.dev``. + 4. Commit ``master``. + 5. Checkout ``features`` and merge with ``master`` (should be a fast-forward at this point). + 6. Update version number in ``_pytest/__init__.py`` to the next minor release: ``"2.10.0.dev"``. + 7. Create a new section in ``CHANGELOG.rst`` titled ``2.10.0.dev``, above ``2.9.1.dev``, and add a few bullet points as placeholders for new entries. + 8. Commit ``features``. + 9. Push ``master`` and ``features``. + + c. **major release (3.0.0)**: same steps as that of a **minor release** -13. **after the release** Bump the version number in ``_pytest/__init__.py``, - to the next Minor release version (i.e. if you released ``pytest-2.8.0``, - set it to ``pytest-2.9.0.dev1``). -14. merge the actual release into the master branch and do a pull request against it -15. merge from master to features diff --git a/tox.ini b/tox.ini index 55b8440df..3c5621315 100644 --- a/tox.ini +++ b/tox.ini @@ -41,7 +41,7 @@ basepython = python2.7 deps = flake8 restructuredtext_lint commands = flake8 pytest.py _pytest testing - rst-lint CHANGELOG.rst + rst-lint CHANGELOG.rst HOWTORELEASE.rst [testenv:py27-xdist] deps=pytest-xdist>=1.13