v0.8.0 release planning #955
Description
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.
Metadata
Metadata
Assignees
Type
Projects
Relationships
Development
Participants
Activity
wholmgren commentedon Apr 23, 2020
Thanks @CameronTStark. We might want to push ahead with an 0.8 release so that API changes don't linger too long.
CameronTStark commentedon Apr 23, 2020
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 commentedon Apr 23, 2020
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 commentedon Apr 23, 2020
The module refactoring / argument renaming is planned for v0.8, according to the roadmap.
In my view, some improvements could be:
pvlib.pvsystem.calcparams_desotooutput withpvlib.pvsystem.singlediodeinput; we can't pipe the output of the first into the second, although conceptually that's how these two functions are used.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 commentedon Apr 23, 2020
I'd really like to see #823 in the next release.
mikofski commentedon Apr 23, 2020
And #717 if I can find the time to finish it, so close
CameronTStark commentedon Apr 27, 2020
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 commentedon Apr 28, 2020
Oh no, not another round of API changes! :(
cwhanse commentedon May 4, 2020
@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 commentedon May 4, 2020
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 moveand a few find/replaces.cwhanse commentedon May 5, 2020
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 commentedon May 18, 2020
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.
[-]v0.7.3 release planning[/-][+]v0.8.0 release planning[/+]CameronTStark commentedon Jun 10, 2020
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- commentedon Jun 24, 2020
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 commentedon Aug 26, 2020
I think it's time for v0.8 issue triage. I'd like to see the items with check boxes completed for v0.8:
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 commentedon Aug 26, 2020
+1 to finishing #708 and related. #708 has had one review (thanks @kanderso-nrel) could use another look, in particular at the API.
kandersolar commentedon Aug 26, 2020
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 commentedon Aug 27, 2020
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 commentedon Aug 27, 2020
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 commentedon Sep 7, 2020
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 commentedon Sep 8, 2020
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???