Skip to content
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

Make a release #299

Closed
consideRatio opened this issue Nov 5, 2019 · 5 comments
Closed

Make a release #299

consideRatio opened this issue Nov 5, 2019 · 5 comments

Comments

@consideRatio
Copy link
Member

I'd like to make a release of oauthenticator. My motivation is mainly to do it alongside a z2jh release I'd like to make. Ping @jupyterhub/jupyterhubteam!

Related instructions on how to do it are drafted in #294.

@manics
Copy link
Member

manics commented Nov 5, 2019

Can we use this as an opportunity to automate the deployment? jupyterhub/team-compass#213 (comment)

I think this repo should be straightfoward to convert since it's a pure python package.

@choldgraf
Copy link
Member

I'm all for it

@willingc
Copy link
Contributor

willingc commented Nov 7, 2019

Before making the release, are there any open PRs that should go into the release? cc/ @minrk

@minrk
Copy link
Member

minrk commented Nov 7, 2019

Looking through PRs, I think we can make a release from master as it is now. There are always future releases.

I'd be happy with following the instructions in #294, or attempting to implement the automated release process. One tool that avoids the objections to versioneer is bumpversion (or punch, but I haven't tried punch before). I've used this in various projects, and it's pretty nice. Versioneer is the only game in town if we want to be able to publish releases entirely from the GitHub website (i.e. create the tag and that's it), but it has its downsides (git archive doesn't work, install from forks can report the wrong version, etc.). With bumpversion, it can at least be entirely scriptable, but does require someone with push access to run some code.

The release process with bumpversion (after initial configuration) looks like:

bumpversion --tag release  # creates commit with 1.2.3-dev -> 1.2.3 and tag 1.2.3
python3 setup.py sdist bdist_wheel
twine upload dist/*
bumpversion --no-tag patch # creates commit with 1.2.3 -> 1.2.4-dev
git push && git push --tags 

This automates only the editing of the version file and creation of tags, but at least enables everything to be fully automatic without editing any files. Push to PyPI from the tag can still be automatic.

@manics
Copy link
Member

manics commented Oct 13, 2020

This is automated 😀

- stage: deploy
python: 3.7
if: tag IS present
deploy:
provider: pypi
user: __token__
# password: see secret PYPI_PASSWORD variable
distributions: sdist bdist_wheel
on:
# Without this we get the note about:
# Skipping a deployment with the pypi provider because this branch is not permitted: <tag>
tags: true

@manics manics closed this as completed Oct 13, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants