Skip to content

v0.14.0 planning #2604

Description

@kandersolar

Time to start thinking about the next release. Here's the current milestone list: https://github.com/pvlib/pvlib-python/milestone/54

I'd like to get these PRs merged:

Please list others that you want to include. And help review!

Activity

  1. added this to the v0.13.2 milestone on Dec 1, 2025
  2. adriesse commented on Dec 2, 2025

    @adriesse
    Member

    I think it's just a matter of turning the latest comments into code.

  3. RDaxini commented on Dec 5, 2025

    @RDaxini
    Member

    Some minor docs changes being made in

    might be worth including

  4. echedey-ls commented on Dec 8, 2025

    @echedey-ls
    Member

    Please list others that you want to include.

  5. kandersolar commented on Dec 15, 2025

    @kandersolar
    MemberAuthor

    I plan to make the release tomorrow, after merging:

    I suppose this release will be 0.14.0 given that we're calling the PSM3 removals "breaking changes":

    Breaking Changes
    ~~~~~~~~~~~~~~~~
    * Following the removal of the NSRDB PSM3 API, the :func:`!pvlib.iotools.get_psm3`,
    :func:`!pvlib.iotools.read_psm3`, and :func:`!pvlib.iotools.parse_psm3`
    functions are removed. (:issue:`2581`, :pull:`2582`)

  6. kandersolar commented on Dec 16, 2025

    @kandersolar
    MemberAuthor

    One more thing to include that I wish I had considered earlier: since this will be v0.14.0 (see above comment), I think we should get #2529 in.

    As a reminder, for the transposition functions that provide return_components=True, that issue is to change the component column names from sky_diffuse, circumsolar, etc to instead be poa_sky_diffuse, poa_circumsolar, etc. It's a breaking change that we can't deprecate (without something like #2530), so "ripping off the bandaid" in a .0 release is as good as we can do. This will pave a consistent path forward for #1553.

    I'll submit a PR for #2529 shortly.

  7. cwhanse commented on Dec 16, 2025

    @cwhanse
    Member

    If we're opening up v0.14 to other breaking changes: #2543 and the bug fix in #2612 although I think I should take over.

  8. wholmgren commented on Dec 16, 2025

    @wholmgren
    Member

    Let's wait until the new year if we're going to make a breaking change. I suspect this will break someone's production code and they will panic to fix it before the holidays.

  9. kandersolar commented on Dec 16, 2025

    @kandersolar
    MemberAuthor

    If we're opening up v0.14 to other breaking changes: #2543 and the bug fix in #2612 although I think I should take over.

    Neither of these would have breaking changes today, would they? Both need deprecations first.

    Let's wait until the new year if we're going to make a breaking change. I suspect this will break someone's production code and they will panic to fix it before the holidays.

    It's a good thought, but the change we're talking about (adding poa_ to a few column names) isn't very difficult to accommodate. And it's always an option to temporarily pin to pvlib<0.14, if they aren't already. Or do I underestimate the issue?

  10. cwhanse commented on Dec 16, 2025

    @cwhanse
    Member

    Neither of these would have breaking changes today, would they? Both need deprecations first.

    Correct. I suppose they can wait, although it would be good to conclude #2543 and include in this release.

  11. wholmgren commented on Dec 16, 2025

    @wholmgren
    Member

    I agree that both options are trivial fixes to you and I. But not if you're the new person debugging failures in a complicated stack while all the senior people are out of office for 1-2 weeks. This is one of the more hostile changes that we can make in that it has no deprecation period and the functions are key parts of many modeling workflows.

  12. kandersolar commented on Dec 16, 2025

    @kandersolar
    MemberAuthor

    Ok, waiting until January it is!

  13. echedey-ls commented on Dec 16, 2025

    @echedey-ls
    Member

    I will be updating #2543 to v0.14 to ease it's inclusion. It's not trivial to change that many v0.13.2's. Thanks for all the work guys.

  14. RDaxini commented on Dec 17, 2025

    @RDaxini
    Member

    If we are waiting until January, #2624 may also be a suitable candidate for the next release.

  15. ramaroesilva commented on Dec 17, 2025

    @ramaroesilva
    Contributor

    Ok, waiting until January it is!

    Great to hear about this. To be honest, the past few months were terrible and I had to stop working on #2529 and it would be much easier to integrate this as an assumedly breaking change.

    @kandersolar if you have other things you could work on, I can take charge (I have it halfway done on my local pvlib clone). Could set this as my 2025 goal :-D A nice follow-up would be to differentiate diffuse/direct IAM losses within the ModelChain.

  16. adriesse commented on Dec 17, 2025

    @adriesse
    Member

    I agree that both options are trivial fixes to you and I. But not if you're the new person debugging failures in a complicated stack while all the senior people are out of office for 1-2 weeks. This is one of the more hostile changes that we can make in that it has no deprecation period and the functions are key parts of many modeling workflows.

    Do people really update pvlib automatically in their workflows? And without some prior testing? And with out the ability to roll back changes? I assume we're talking about commercial users here.

  17. RDaxini commented on Jan 7, 2026

    @RDaxini
    Member

    What is the planned release date now?

  18. kandersolar commented on Jan 13, 2026

    @kandersolar
    MemberAuthor

    What is the planned release date now?

    I arbitrarily nominate Jan 15 (this Thursday). I'm catching up on pvlib notifications today and will push on remaining release items after that.

  19. changed the title [-]v0.13.2 planning[/-] [+]v0.14.0 planning[/+] on Jan 16, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions