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

Summary of an approximate procedure to cut a release for a jupyterhub project #563

Closed
consideRatio opened this issue Sep 8, 2022 · 2 comments

Comments

@consideRatio
Copy link
Member

consideRatio commented Sep 8, 2022

UPDATE

Reference https://jupyterhub-team-compass.readthedocs.io/en/latest/practices/releases.html for details about this going onwards.


Just wanted to document briefly an approximate procedure I find myself following when making a release for some project in our organization.

  • git checkout main -> git pull
  • github-activity --heading-level=3
    • PR labelling: I read the output of github-activity and look for PRs under the uncategorized heading that didn't have a label for github-activity to sort it by. If I find non-bot PRs there I visit them and add a relevant label. github-activity can't sort ci labels automatically to go under a ### Continuous integration improvements heading but I handle those manually.
    • PR title updates: I read the output of github-activity and look for PRs with a title that can be improved and updates the title of the PR on GitHub. For example in jupyterhub/oauthenticator I think its relevant that all PRs associated with a specific authenticator leads with that in the title, such as [GitHub] Fix ....
  • github-activity --heading-level=3 (again)
  • Copy and paste the output into from github-activity to the changelog and refine it manually:
    • Decide a version increment.
      • Bump major version if a breaking change is introduced.
        • If a major version bump is made, also write some summary manually before listing all the PRs.
      • Bump minor version if an enhancement or new feature is added
      • Bump patch version if only documentation and bugfixes etc are provided.
    • Add a date to the release that seems likely to match when it can get merged
    • Remove various pre-commit PRs and dependabot PRs that just bumps CI stuff.
    • Remove various @welcome, @dependabot, and other bots from contributors lists etc
    • Put ci labelled PRs manually under ### Continuous integration improvements heading
  • Make a commit named like Add changelog for 1.2.3 and open a PR with it titled the same
  • Await merge, and when its merged follow the instructions described in RELEASE.md
@consideRatio consideRatio changed the title How I typically cut a release Summary of an approximate procedure to cut a release for a jupyterhub project Sep 8, 2022
@choldgraf
Copy link
Member

This is great - could we encode it in the team compass somehow as a checklist that could be pasted into an issue?

@consideRatio
Copy link
Member Author

I've updated the original issue description to link to https://jupyterhub-team-compass.readthedocs.io/en/latest/practices/releases.html going onwards, which should be fine once we get #679 through.

Closing this pre-emptively, its anyhow just a "info" issue rather than something we should take action on.

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

2 participants