release 0.15.4

[drammock]

@trallard now that @larsoner has tracked down the cause of SciPy's build errors (and it's not the theme's fault, see #1859 / https://github.com/scipy/scipy/pull/20897), we have marked the theme as parallel_write_safe=True again. This is a big enough pain point (cf #1643 comments) that I think we should push out a release for it this week. OK with you? Anything that you or @gabalafou want to squeeze in before I cut an RC?

[trallard]

I am in favour of a release. So far I have nothing that could constitute a release block or similar

[drammock]

argh, I didn't get to it last week and now I don't have time to do an RC-wait3days-release cycle before I head on holiday (in 2 days). Maybe @trallard or @Carreau can do a release without me, otherwise it will have to wait until July. (or @12rambau if he's not busy)

[12rambau]

@trallard do you want me to do a release or an RC ? I'll do it tomorrow morning

[trallard]

It's up to you @12rambau if you have some time. Otherwise I can help with the RC and cut a proper release early next week (I am taking time off Thursday-Sunday).

Just lmk what you prefer 😉

[12rambau]

I'll do a RC-wait3days-release no worries

[12rambau]

Double check for quality-control

• [x] There are no open issues with a impact: block-release label

Prepare the codebase for a new version

• [x] Bump __version__ in __init__.py
• [x] Update our version switcher .json file with the new version
• [x] Make a release commit: git commit -m 'bump: 0.1.9 → 0.2.0'
• [x] Push the RLS commit git push upstream main
• [x] If a release candidate is needed, tick this box when we're now ready for a full release.

Make the release

• [x] Start a new 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.
  • Generate the automatic release notes, eventually manually specify the previous version (useful when several release candidate have been made)
• [x] Confirm that the release completed
  • The publish github action job has completed successfully in the actions tab.
  • The PyPI version is updated
• [x] Hide the previous patch version build in the RDT interface if needed.
• [x] Celebrate, you're done!

[^release-refs]: Taken from the release checklist. See the release documentation for an overview of release processes.

[dbitouze]

What would be nice for people who would like to help by testing, is a reminder of the command line to execute to install the release candidates. I'm not sure where this should appear: here, on the corresponding changelog pages, on the wiki, etc.?

[drammock]

@dbitouze

a reminder of the command line to execute to install the release candidates

pip install --pre pydata-sphinx-theme (the --pre flag is what allows pip to install release candidates)

[dbitouze]

@drammock Thanks! But, if this command is written only here, there are chances that nobody will remind where to find it for the next RCs :grin:

[Carreau]

see #1891 on how to try alpha, beta, rc, nightly.

[12rambau]

@Carreau and @trallard I checked what was merged on main since last week and nothing should disturb the release. Maybe for next one we should avoid merging during the release candidate period to avoid bad surprises what do you think ?

[trallard]

Oops my bad 😔 will make sure to remember