Prepare v0.13 release - Githubissues

jupyterhub / firstuseauthenticator

JupyterHub Authenticator that lets users set passwords when they first log in

BSD 3-Clause "New" or "Revised" License

48 stars 31 forks source link

Prepare v0.13 release #27

Closed GeorgianaElena closed 4 years ago

GeorgianaElena commented 4 years ago

Preparing the release of FirstUseAuthenticator v0.13.

Thanks to the amazing work done in oauthenticator and chartpress (:heart:), we can follow the same release pattern for FirstUseAuthenticator.

ToDos:

[x] release tagged builds to PyPi using Travis
[x] add a changelog.md
[x] add a release.md describing the release steps

Closes https://github.com/jupyterhub/firstuseauthenticator/issues/26

consideRatio commented 4 years ago

Nice work! Time to try out the release instructions now then! :)

GeorgianaElena commented 4 years ago

@consideRatio, I addressed your feedback (thanks a lot for your patience :dog:).

I added the changelog also, but there is something I don't fully understand.

Right now, there are "unreleased" changes in the changelog that will later be in v0.13. After this PR is merged, according to the release instructions, before making the release I should modify the changelog and add the changes as v0.13, right? How do I properly link the GitHub listing of changes in the changelog if the release 0.13 doesn't exist at the time I modify the file?
Should https://github.com/jupyterhub/firstuseauthenticator/pull/21 be in this release? I will try to remember what I did in that PR (it's been a while since I last checked it out) and address your feedback. I'm ok if we wait for the next release also.

consideRatio commented 4 years ago

You can reference a tag like [0.13.0] and github will figure it out when viewing this markdown file on github itself.

Make a commit without a PR to update the changelog with release date and make the [unreleased] section become a [0.13.0] section etc.
Make a commit with the version changes etc
Make a commit to reset the version to 0.13.1.dev (message "back to dev" has typically been used)

Push changes. Tag the pushed commit with version being 0.13.0. Push the tag reference. Verify travis builds and deploys a PyPI release successfully.

before you make the version changes that you also commit and push, and then later tag to be 0.13.0.

Lets do more quick increments instead and let 0.14.0 follow quickly after 0.13.0 with that unmerged PR. I'd suggest you give it a self-review again, ping me who tries to review it without much insight but do my best anyhow, and the we merge it if it seems ok to us.

GeorgianaElena commented 4 years ago

@consideRatio, shouldn't travis trigger for both "release 0.13.0" and "back to dev" commits? https://travis-ci.org/jupyterhub/firstuseauthenticator/builds?utm_medium=notification&utm_source=github_status

Update: I think it's all ok now and we have a new release :). I overlooked something though... The other tags had a "v" in front of the number (e.g. v0.13.0) and unfortunately I didn't notice beforehand. Do you think this causes any issues?

consideRatio commented 4 years ago

No if you push once with 100 commits it will only run once for the last commit. If you push 100 commits and two tags referencing two of these commits, it will run three times, one per tag and the final commit.

If a tag was or wasnt prefixed v is of very low importance i think, we dont read the tag name specifically at any place in our CI/CD pipeline currently. The PyPI released version is set in setup.py (referenced from someplace else)

consideRatio commented 4 years ago

:heart: :tada: excellent work!

GeorgianaElena commented 4 years ago

I started panicking when I saw that my release looked different from the other ones here https://github.com/jupyterhub/firstuseauthenticator/releases :smile_cat:

Thanks a lot for your help and patience @consideRatio :heart: