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.