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

Read the docs v0.10 not in stable? #1798

Closed
mikofski opened this issue Jul 1, 2023 · 5 comments
Closed

Read the docs v0.10 not in stable? #1798

mikofski opened this issue Jul 1, 2023 · 5 comments

Comments

@mikofski
Copy link
Member

mikofski commented Jul 1, 2023

Describe the bug
At the documentation does not shoot v0.10 in “stable,” only as “latest”

To Reproduce
Go to https://pvlib-python.readthedocs.io/en/stable/whatsnew.html

Expected behavior
this page should show v0.10

Screenshots
image

Versions:

  • pvlib.__version__: v0.10

Additional context
Also note the url for read the docs in GitHub releases (https://github.com/pvlib/pvlib-python/releases/tag/v0.10.0) is wrong

@kandersolar
Copy link
Member

Yes, see #1796. tl;dr pvfactors requires pvlib<0.10, so the v0.10.0 docs build failed because it requires pvfactors.

@kandersolar
Copy link
Member

Unfortunately I don't see a way to fix this that doesn't involve editing v0.10.0, which I think is a non-starter. At least stable is updated now after #1797 and tagging v0.10.1.

One thing to look into and possibly fix is why RTD treated the overall build as a failure (and didn't host the build results) just because of an issue in the example gallery. sphinx-gallery is supposed to be able to handle broken examples; see e.g. https://sphinx-gallery.github.io/stable/auto_examples/index.html. Failing the entire build due to gallery errors is useful for PR builds, but for a release I think we would much rather have the build be treated as a success, even if there are issues in the gallery or elsewhere.

@wholmgren
Copy link
Member

wholmgren commented Jul 5, 2023

Thanks for the quick fix Kevin! If I understand correctly, we could have avoided the problem if we 1. always issue a prerelease and 2. test the code and docs in a GitHub action as part of the release pipeline. Is that correct and reasonable?

@kandersolar
Copy link
Member

I think so. Testing on the prerelease tag also catches any missed fail_on_pvlib_version tests. I support automating it; its current manual state is evidently error-prone, at least if I'm the one doing it.

I have avoided making prereleases in the past so as to not clutter up the GH and PyPI releases pages. But a bit of "clutter" is well worth preventing this from happening again IMHO :)

@jules-ch
Copy link
Contributor

jules-ch commented Aug 2, 2023

It's not really worth it since it's been fixed on 10.1 IMO

@mikofski mikofski closed this as completed Aug 2, 2023
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

4 participants