v0.13.2 planning

[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:

• [ ] #2491, if reviewers can be satisfied
• [x] #2572
• [x] #2591
• [x] #2600
• [x] #2609

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

[adriesse]

• Add polo-smm #2491, if reviewers can be satisfied

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

[RDaxini]

Some minor docs changes being made in

• [ ] #2610

might be worth including

[echedey-ls]

Please list others that you want to include.

• [x] #2615 pretty please.

[kandersolar]

I plan to make the release tomorrow, after merging:

• #2491
• #2623

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

https://github.com/pvlib/pvlib-python/blob/9e267ca1b7996ca083c0f96efefbb6bf957cc954/docs/sphinx/source/whatsnew/v0.13.2.rst?plain=1#L7-L11

[kandersolar]

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.

[cwhanse]

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.

[wholmgren]

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.

[kandersolar]

If we're opening up v0.14 to other breaking changes: https://github.com/pvlib/pvlib-python/pull/2543 and the bug fix in https://github.com/pvlib/pvlib-python/pull/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?

[cwhanse]

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.

[wholmgren]

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.

[kandersolar]

Ok, waiting until January it is!

[echedey-ls]

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.

[RDaxini]

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

[ramaroesilva]

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.

[adriesse]

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.