v0.14.0 planning

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:

Add polo spectral factor model #2491, if reviewers can be satisfied
Add function for accessing MERRA-2 #2572
Add guidance about temperature modeling to User Guide #2591
Pandas deprecations #2600
Fix failing iotools tests #2609

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

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

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

Some minor docs changes being made in

Fix broken GitHub contributor links in whatsnew docs #2610

might be worth including

Please list others that you want to include.

Fix test for _fit_sandia_cocontent #2615 pretty please.

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

pvlib-python/docs/sphinx/source/whatsnew/v0.13.2.rst

Lines 7 to 11 in 9e267ca

    
           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`)

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.

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.

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.

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?

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.

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.

Ok, waiting until January it is!

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.

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

@kandersolar

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.

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.

What is the planned release date now?

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.

Navigation Menu

Repository navigation

v0.14.0 planning #2604

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	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`)

v0.14.0 planning #2604

Description

Activity

adriesse commented on Dec 2, 2025

RDaxini commented on Dec 5, 2025

echedey-ls commented on Dec 8, 2025

kandersolar commented on Dec 15, 2025

kandersolar commented on Dec 16, 2025

cwhanse commented on Dec 16, 2025

wholmgren commented on Dec 16, 2025

kandersolar commented on Dec 16, 2025

cwhanse commented on Dec 16, 2025

wholmgren commented on Dec 16, 2025

kandersolar commented on Dec 16, 2025

echedey-ls commented on Dec 16, 2025

RDaxini commented on Dec 17, 2025

ramaroesilva commented on Dec 17, 2025

adriesse commented on Dec 17, 2025

RDaxini commented on Jan 7, 2026

kandersolar commented on Jan 13, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions