search

neovim / pynvim

Python client and plugin host for Nvim
http://pynvim.readthedocs.io/en/latest/
Apache License 2.0
1.52k stars 118 forks source link

Release process: document, automate #428

Closed blueyed closed 4 years ago

blueyed commented 4 years ago

For easier releases it would be nice if tags get deployed via Travis.

See https://github.com/Vimjas/vint/blob/db881f8fe7127cd092436371643e48903099f114/.travis.yml#L38-L53 for reference - it uses a token generated via PyPI's admin interface.

justinmk commented 4 years ago

IIUC you're suggesting that when a human creates a tag, that should trigger CI to publish to pypi.

That could be nice, although it depends on how cumbersome the release process is. I would guess if we just document it like the lua-client repo that would solve 80% of the friction.

blueyed commented 4 years ago

The main benefit here is also to ensure a predictable environment, to not include/upload unwanted files (just happened with pip 20 even (https://github.com/pypa/pip/pull/7624)).

bfredl commented 4 years ago

to not include/upload unwanted files

Currently I do this by diffing every release tarball against the last one. But if someone wants to write a nice script, that would be a welcome addition.

justinmk commented 4 years ago

@bfredl are the steps to release written down somewhere? I actually have never done it for this repo, thus can't write them myself.

bfredl commented 4 years ago

@justinmk Currently only in my zsh_history, but I will write something down (but nothing unexpected, really). But probably we want to improve the process to include the disabling of excessive logging (there is a script somewhere we could revive)

I think currently I'm the only one having ownership on the pynvim pypi package, I could add you to it if you have a pypi account.

bfredl commented 4 years ago

I just made a release, and wrote down what I did at the same time:

  1. Create a release commit with the title "Pynvim x.y.z"

    • list significant changes in the commit message
    • bump the version in pynvim/util.py and setup.py (3 places in total)

  2. Make a release on github with the same commit/version tag and copy the message.

  3. run scripts/disable_log_statements.sh

  4. run python setup.py sdist

    • Here I usually diff the release tarball dist/pynvim-x.y.z.tar.gz against the previous one

  5. run twine upload -r pypi dist/pynvim-x.y.z.tar.gz (assumes you have a pypi account with permissions)

  6. run scripts/enable_log_statements.sh or git reset --hard to restore the working dir

justinmk commented 4 years ago

Thanks, documented in https://github.com/neovim/pynvim/pull/429.

That should be enough. I strongly believe we shouldn't spend time automating this in CI. Parts of it can't be automated (e.g. human needs to write the release notes, human needs to authenticate to pypi), and other parts are trivial compared to those tasks.

Something like a scripts/release.sh could be useful though. Just don't want to spend time babysitting CI stuff that will no doubt break in the future.

justinmk commented 4 years ago

run twine upload -r pypi dist/pynvim-x.y.z.tar.gz (assumes you have a pypi account with permissions)

I guess this replaces publish.sh ?