Upcoming whatsnews can't be tested on RTD CI

[echedey-ls]

Problem
Adding a version whatsnew to the whatsnews index at the end of a development cycle makes it difficult to test the rendering of the whatsnews page.
Also, it makes checking the latest ReadTheDocs whatsnews page useless, since it won't have the latest changes entries.

Describe the solution you'd like
Modify release instructions to add the next whatsnew file to the whatsnews page on a commit right after the tagged commit.

Describe alternatives you've considered
None. We can't add that file in the same version release PR since it would show up in the stable build.

The other alternative is to continue checking that locally (I really dislike that, I need to switch branches in an smaller timespan than a PR review 🤠)

Secondary effects
Next release schedule will show up in the latest docs branch, which some users may find useful.

[kandersolar]

FWIW, I don't consider it crucial that whatsnew entries render perfectly when each PR gets merged. That's because we can always clean it up in the "finalize release" PR, when we are already making changes to that file anyway (updating release date, listing missed contributors, etc). So as far as reviewing the whatsnew entry in each PR, I personally don't mind just checking the un-rendered RST, and it's no big deal if we overlook some syntax issue, since we have an easy opportunity to fix it later.

However, even if it's not required, I agree that it is nice to have the upcoming whatsnew page included in latest and in PR builds. What often happens is that we just edit the whatsnew index as part of whatever normal PR comes next after each release (check the blame for that file to see that most entries are made in random PRs). Sometimes nobody ever makes the change, so it gets left until the end of the development cycle, like what happened with v0.10.5. But we could certainly start doing an immediate follow-up PR after each release like you suggest.

Anyway, that's just a bit of background information. I don't feel strongly one way or the other :)

[echedey-ls]

Thanks for the context, thou I was aware of the last-minute fixes. It's also just to leverage future work and allow us contributors to be equally functional at checking the whatsnew. You know I'm kinda a fan of leveraging maintainer tasks.

Feel free to close this issue even if no action is deemed to be taken.

I'll leave you a comment here below regarding the release procedure wiki entry. I find it overly complex, and if I were to update it, I would
consider the index down below as a possibility. IMO, what needs to be done should more streamlined in the instructions.

Before any [pre-]release

Check thingies

Pre-releases

check before any release, and do a PR with fixes

Releases

check before any release, and do a PR with fixes

From GitHub (recommended or not, who knows)

From local branch

what to do if CI fails at uploading the new version

• check logs
• manually upload to PyPI (link)

Update conda-forge recipe

Post-release TODO list

• Publicize release

• Check the Zenodo integration

• Update Wikipedia version

• Start new version

  • Add next whatsnew and include it in whatsnews index
  • Milestone updates?

Obsolete instructions

In case the world catches on fire

• Upload to PyPI Manually

• Upload to Anaconda.org (obsolete)

[AdamRJensen]

I support adding an extra step to the release procedure, where the responsible person commits a PR right after a new release that adds the whatsnew page.

[kandersolar]

I've made some improvements to the release procedure along these lines, including the main suggestion of including the new whatsnew page in the docs immediately after the release :)

https://github.com/pvlib/pvlib-python/wiki/Release-procedures

Thanks for pursuing these improvements, @echedey-ls!

[echedey-ls]

That's amazing @kandersolar !! Feel free to close this issue at your will 😄