dependency chain and compatability with portaldata update

[juniperlsimonis]

the update to portal data v2 meant that fill_missing_weather needed to be updated for the new file format. this update has been incorporated, so there is no need to edit the code.

fill_missing_weather is also being tested at a level that would have (and did) catch the break (i.e. cause a fail) with the update to the data, so there's no need to necessarily add any tests to address this.

the change within portalr isn't very big, but because of the change to portal data being backwards-compatibility-breaking, the change was also backwards-compatibility-breaking for portalr, such that anyone who uses portal data and grabs the newest version of the data will have to have the newest version of portalr, which is not the CRAN version (at least not yet?).

i'm not entirely sure of what the best way to manage this dependency chain, but perhaps there's a way to do something in the downloading of the data function? like maybe the portaldata version has some info about what version of portalr should be used with it and then notifies the user if it's out of date?

open to thoughts on this @ethanwhite @gmyenni @ha0ye

[ha0ye]

Hmmm, yeah, my initial reaction is that portalr functions could check version compatibility when downloading...

but if what you say is true, the versions of portalr out there now don't have code to check, and when they try to download the latest data... bad things happen?

And to get them the version of portalr with the version checking means they'll also get the fixes to work with the latest version of portal data...

I think we should probably split into 2 issues to resolve:

• is there a way to make portal data v2 compatible with older portalr
• future-proofing further changes to portal data format.