New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New maintainer release checklist #314

Merged
merged 4 commits into from Mar 18, 2018

Conversation

Projects
None yet
4 participants
@brainwane
Member

brainwane commented Mar 2, 2018

  • Add readme-checking with readme-renderer to tox doc tests
  • Add checklists for "add a new maintainer" and "cut a new release" to Contributing doc

This is really for my own use because I absolutely need a checklist for stuff like this. Followup to #306.

@codecov

This comment has been minimized.

codecov bot commented Mar 2, 2018

Codecov Report

Merging #314 into master will not change coverage.
The diff coverage is n/a.

Impacted file tree graph

@@           Coverage Diff           @@
##           master     #314   +/-   ##
=======================================
  Coverage   69.53%   69.53%           
=======================================
  Files          12       12           
  Lines         581      581           
  Branches       91       91           
=======================================
  Hits          404      404           
- Misses        149      150    +1     
+ Partials       28       27    -1
Impacted Files Coverage Δ
twine/wininst.py 29.72% <0%> (ø) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 4a8c3d4...cc480ab. Read the comment docs.

@mauritsvanrees

This comment has been minimized.

Contributor

mauritsvanrees commented Mar 5, 2018

Thanks for making this checklist!
For testing zest.releaser this would work (testing with Python 2.7 here, but 3.6 should work too):

maurits@mauritsbook:tmp $ virtualenv test
New python executable in test/bin/python2.7
Also creating executable in test/bin/python
Installing setuptools, pip, wheel...done.
maurits@mauritsbook:tmp $ cd test
maurits@mauritsbook:test $ . bin/activate
(test)maurits@mauritsbook:test $ pip install --upgrade --pre --index-url https://test.pypi.org/simple/ --extra-index-url https://pypi.org/simple twine
...
(test)maurits@mauritsbook:test $ pip install --upgrade zest.releaser
...
(test)maurits@mauritsbook:test $ cd ~/own/mauritstestpackage/
$ fullrelease  # Note: this asks a few simple questions.
INFO: Starting prerelease.
...
INFO: Starting release.
Tag needed to proceed, you can use the following command:
git tag 1.24.4 -m u'Tagging 1.24.4'
Run this command (Y/n)? 
...
Upload to pypi (Y/n)? 
Uploading mauritstestpackage2-1.24.4-py2-none-any.whl
100%|██████████| 10.3k/10.3k [00:01<00:00, 6.79kB/s]
Uploading mauritstestpackage2-1.24.4.tar.gz
100%|██████████| 8.70k/8.70k [00:01<00:00, 7.73kB/s]
INFO: Starting postrelease.
...

It is best to test it out by releasing a real package. Above, I use a basically empty test package for that. zest.releaser uses your ~/.pypirc, so if you only have the test pypi index listed there, it should be fine to release any package.

You may want to force zest.releaser into creating a wheel, next to a plain sdist, by adding this to setup.cfg or ~/.pypirc:

[zest.releaser]
create-wheel = yes

But if you have [bdist_wheel] universal = 1 in setup.cfg, then it will already create wheels. (I can imagine that we make creating wheels as well the default at some point.)

mplanchard added a commit to pypiserver/pypiserver that referenced this pull request Mar 7, 2018

Provide Prerelease Testing for Twine
Resolves #203
Related to pypa/twine#314

This commit adds an ``sh -c`` call, whose argument is the value of the
environment variable ``PYPISERVER_SETUP_CMD``, or ``true`` if that
variable is not set. This was specifically added to enable the
``pre_twine`` environment, which is provided to automatically test
pre-releases of twine, both for our use (e.g. #203) and for the use of
the twine maintainers (pypa/twine#314).

The capacity to specify an arbitrary setup command via an environment
variable may also wind up being useful in other cases in the future.

In addition, the envlist is updated to include only Python versions we
actually support.

This commit also alphabetizes the ``dev.pip`` requirements and rmeoves
specific requirements for testing using Python 2.5 (which we do not test
against anymore).

mplanchard added a commit to pypiserver/pypiserver that referenced this pull request Mar 7, 2018

Provide Prerelease Testing for Twine
Resolves #203
Related to pypa/twine#314

This commit adds an ``sh -c`` call, whose argument is the value of the
environment variable ``PYPISERVER_SETUP_CMD``, or ``true`` if that
variable is not set. This was specifically added to enable the
``pre_twine`` environment, which is provided to automatically test
pre-releases of twine, both for our use (e.g. #203) and for the use of
the twine maintainers (pypa/twine#314).

The capacity to specify an arbitrary setup command via an environment
variable may also wind up being useful in other cases in the future.

In addition, the envlist is updated to include only Python versions we
actually support.

This commit also alphabetizes the ``dev.pip`` requirements and rmeoves
specific requirements for testing using Python 2.5 (which we do not test
against anymore).
@mplanchard

This comment has been minimized.

mplanchard commented Mar 7, 2018

As of the current master, pypiserver supports running tox with tox -e pre_twine to test all supported environments against the prerelease of twine, so you could automate with git clone git@github.com:pypiserver/pypiserver && cd pypiserver && tox -e pre_twine if desired!

Thanks again for reaching out! It's super, super nice to be able to be sure that new versions of twine aren't going to break things for our users.

@sigmavirus24

This comment has been minimized.

Member

sigmavirus24 commented Mar 7, 2018

@mplanchard does that mean you're also willing to be tagged into issues where this breaks things because of problems in pypiserver? Alternatively, is there a stable branch that can be tested against?

@mplanchard

This comment has been minimized.

mplanchard commented Mar 7, 2018

@sigmavirus24 absolutely! I'd definitely prefer to know and fix things prior to it becoming a problem outside of the pre-release world. Generally, master is our stable branch, and the source of our deployments when we do releases, so testing against that is preferred.

@brainwane brainwane referenced this pull request Mar 16, 2018

Merged

Release 1.11.0 #321

@brainwane brainwane changed the title from WIP: New maintainer release checklist to New maintainer release checklist Mar 18, 2018

@brainwane

This comment has been minimized.

Member

brainwane commented Mar 18, 2018

Thanks, @mauritsvanrees, @mplanchard, and @hpk42 for help here and in IRC. I've added your advice to this checklist.

Of course, I'm also open to maintainers of other packaging/distribution tools speaking up, here or in new GitHub issues in this repo, to tell me what steps I could add to this release checklist to find out early if Twine breaks something for you. (We keep our master branch in a reasonably release-ready state, so you could also feel free to test against that in your own setups!)

@brainwane brainwane merged commit 7aeebc2 into pypa:master Mar 18, 2018

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

@brainwane brainwane deleted the brainwane:new-maintainer-release-checklist branch Mar 18, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment