Release

[choldgraf]

• Bump __version__ in __init__.py. Use semantic versioning to decide whether it's a major, minor, or patch bump.
• Make a release commit: git commit -m 'RLS: v0.2.0'
• Push the RLS commit git push upstream master: RLS: v0.8.0 #530
• Make a GitHub release
  • Call the release the current version, e.g. v0.2.0
  • In the Choose a Tag: dropdown, type in the release name (e.g., v0.2.0) and click "Create new tag"
  • In the Target: dropdown, pin it to the release commit that you've just pushed.
  • Add release notes in the field below (if it's a minor/major version bump)
    If you wish, use github-activity to generate a changelog, eg github-activity pydata/pydata-sphinx-theme --since v0.2.2 --until v0.3.0.

CANCELED THE RELEASE PROCESS HERE

• Confirm that this github action job has completed successfully in the actions tab
• Confirm that the PyPI version is updated
• Celebrate, you're done!

[jorisvandenbossche]

I didn't yet have time to look into #502 (comment), but since that's a regression, I would like to see it either fixed or reverted for now, before doing a release.

[choldgraf]

hmm - do we have that encoded in an issue? Given that we've already made a release since that PR was made, I think we've already shipped this regression. For now, I've stopped the release process and will delete the tag.

But FWIW, I think we should just release early and often even if there are minor regressions, as long as there's an issue to track the improvement, unless the regression is really major.

If we have an issue that we think must block a release, why don't we use a github label for this like block-release? Otherwise it'll be really hard to know when to intentionally not release. And I think it's important to make the explicit decision "this issue is important enough that all releases should be blocked until it is fixed", otherwise the bar will be quite low and under-specified to block things.

[jorisvandenbossche]

Yeah, I should already have long ago created an issue, sorry .. Or just reverted it once I discovered the regression, until we have a fix (which would ensure master is in a releasable state)

I think it's a good idea to have a policy about having the main branch in a releasable state (so someone can always do a release), and if not have a label for issues that would block a release, as you propose.

Given that we've already made a release since that PR was made, I think we've already shipped this regression.

The previous release was from a branch, so didn't include that commit

[jorisvandenbossche]

BTW, I think it's a relatively major regression, if you have a site with a sidebar that doesn't fit a single page, then it's quite unusable if it doesn't center on where you are.

But I can also take a look at it now, so we can do a 0.8.1 release quickly instead of deleting 0.8.0

[choldgraf]

I've already stopped the release process, so we don't need to release something new right now, but happy to discuss w/ you and re-release if you like. The main reason that I wanted to release now was because I consider #526 to be a pretty big bug (on sites w/o an image logo, the text padding is pretty bad right now).

I opened up #532 to discuss a release policy, so we don't lose track of that one. Happy to iterate there.