v0.8.0 release planning

[CameronTStark]

This issue is to centralize the discussion of what will be in the v0.7.3 release. It is the forum for the the community to voice support for certain enhancements to be prioritized for the release that will then inform the milestones.

Please try to centralize your thoughts and discussion about the next release here or by numerical reference from another issue/PR E.g. #XYZ.

The GitHub milestone feature is used as a means of labeling what is planned to go into the next and subsequent releases.

The person assigned to this issue is "release manager". It is their role to track how current issues, PRs and bugfixes will add up to a release and ultimately perform that release.

To start the conversation, please discuss what you think about what's currently listed on the v0.7.3 milestone and if there's a reason to add more or remove something.

[wholmgren]

Thanks @CameronTStark. We might want to push ahead with an 0.8 release so that API changes don't linger too long.

[CameronTStark]

That sounds good. Can we align what's on the Development Roadmap for v0.8.0 or should we forego that just so it's clear that there are breaking changes happening?

It would be ideal if we could at least pick the lowest hanging fruit in the process.

[mikofski]

Maybe we should consider using GitHub projects (or Trello) as a segue or go between the roadmap in the wiki and the v0.8 milestones?

Sometimes it helps to have work organized in cards so you can reprioritize, drag them around, group, rank, etc. I believe GH projects links to issues and milestones automatically which could be convenient.

We might need to choose a product manager to curate the project board, it's busy-body work but we can rotate like the release manager.

[cwhanse]

The module refactoring / argument renaming is planned for v0.8, according to the roadmap.

In my view, some improvements could be:

• normalizing the parameter names involved in single diode models, and maintaining the same order. Compare pvlib.pvsystem.calcparams_desoto output with pvlib.pvsystem.singlediode input; we can't pipe the output of the first into the second, although conceptually that's how these two functions are used.
• further separating of pvlib.pvsystem, e.g. Create inverter.py #886 for inverters, breaking out the DC models.
• work on ModelChain to provide multiple entrypoints, Run ModelChain from POA irradiance #943 may be a start.
• rethink (if needed) how pvlib manages model parameters. PVSystem.module_parameters (which is also expected to include IAM model parameters), PVSystem.temperature_model_parameters, PVSystem.inverter_model_parameters, PVSystem.losses_parameters, you get the point. Maybe this is the right design pattern, but I think it's more of an accumulation that's worth a second look.

[mikofski]

I'd really like to see #823 in the next release.

[mikofski]

And #717 if I can find the time to finish it, so close

[CameronTStark]

Maybe we should consider using GitHub projects (or Trello) as a segue or go between the roadmap in the wiki and the v0.8 milestones?

I setup a v0.8.0 GH Project for our use to try it since it sounds like a good idea. I've disabled most of its automation because it adds new issues and PRs automatically without the ability to do so only if they have the v0.8.0 milestone.

I'm not sure this has utility above just sorting by the milestone in the issues/PRs tabs and centering the discussion there though.

I'll leave the project up for a bit just as an example to let maintainers poke at it to see if they can see a productivity advantage.

[adriesse]

Oh no, not another round of API changes! :(

[cwhanse]

@CameronTStark are we going to v0.8 or v0.7.3 next? Either way is fine with me. Please set up a whatsnew file for the next release.

[CameronTStark]

Just to get things moving we should just use the current v0.7.3.rst currently in place (I need to rename it since it's missing the v). If the API breaking changes occur that you've suggested we can easily change it to v0.8 with just a quick git move and a few find/replaces.

[cwhanse]

OK. #708 and #886 both change the API. #886 we can deprecate, I don't think it's worth deprecating for #708 if it goes in the next release. I'm willing to start on #894 with #958, that will have API changes.

[CameronTStark]

I've changed the milestone for this issue since, per a phone discussion, we've decided to push on to v0.8.0.

Milestones of other issues will change however not all that are currently 0.7.3 will be converted to 0.8.0; some will be untagged.

From now on, tagging a PR/issue with a milestone will show the intention to address it within the given release. If a PR stagnates after being given a milestone, that milestone may be bumped or dropped. This keeps the milestone's ability to communicate fresh rather than an archive of best intentions.

If you find a milestone you disagree with please highlight it. These conversations are what these milestones are meant to drive.

[CameronTStark]

Hey all,

I've mentioned this to @cwhanse and @wholmgren but I wanted to let the community know that I'm transitioning to a new position outside of PV and won't be able to support pvlib-python as a maintainer or as the v0.8.0 release manager.

The other maintainers are working now to fill this gap and I expect that this issue will be headed by a new person in the coming days.

Best wishes for the continued success of this project!

[bt-]

Hello pvlib maintainers, thanks for all the hardwork on this package!

I was just exploring how to use ModelChain starting with POA irradiance measured by a pyranometer and eventually ended up here, so I'd like to put in a vote of support for including #943 in the v0.8 release.

[wholmgren]

I think it's time for v0.8 issue triage. I'd like to see the items with check boxes completed for v0.8:

• ENH: Port PVsyst and Desoto parameter estimation from MATLAB #708, Refactor CEC SDM fit test #956, Refactor CEC SDM fit test (#956) #957
• Run ModelChain from POA irradiance #943
• Added irradiance_loss_pvsyst function to pvsystem #1000
• Adds ability for soiling.Hsu to accept arbitrary time intervals (other than 1 hour) #980
• Add hsu soiling model gallery example.  #990
• remove tools._array_newton #972
• TEMPERATURE_MODEL_PARAMETERS is undocumented #939
• remove **kwargs from PVSystem, ModelChain, Location #1029
• change whats new API section names #1009, other whats new clean up, and this
• Singleaxis tracking with non-parallel slope #823
• Add pvlib.temperature.fuentes #1037

The issues marked X were previously mentioned in this thread as candidates for this release but I think they should be pushed to another release unless there's a commitment to finish in the next 2 weeks:

X #894
X #958
X #717

All other issues/PRs marked 0.8.0 and not discussed here can be pushed off too.

[cwhanse]

+1 to finishing #708 and related. #708 has had one review (thanks @kanderso-nrel) could use another look, in particular at the API.

[kandersolar]

I volunteer to pick up the soiling.hsu PRs #980 and #990, they don't need much. #823 was put on hold until @mikofski and I finished writing up the report on it, which is now done. Mark, will you have time to finish #823 for v0.8? If not, I can take a look at it.

[mikofski]

Hi @kanderso-nrel I'm not sure what still needs to be done for #823 I thought it was ready for review. We had toyed with changing the rotation matrices to an algebraic approach, but I thought you had backed off of that, right? Maybe update the citations to match the slope aware backtracking report?

[mikofski]

I'm okay with postponing #717. I'll put some work into it, but I don't want it to hold up the release

[wholmgren]

I pushed a 0.8.0-beta release. I'll make a final release once #1052, #1053, and #1054 are reviewed and merged. I'm hoping that can happen tomorrow.

[wholmgren]

0.8.0 is on PyPI and the pvlib conda channel. It should be available on conda-forge within an hour or so.

Thanks @mikofski @kanderso-nrel @cwhanse for the big push to finish this release over the last few weeks.

The next one will be smaller, right???