Prepare for GIS4WRF 0.14.2 release

[letmaik]

• [x] Create a new issue named Prepare for GIS4WRF 0.14.2 release, copy and paste this check-list, and tick what is appropriate.
• [x] Create a milestone for the version to release if not done already.
• [x] Check that all issues and PRs targeting the new release have been addded to the milestone.
• [x] Check that the documentation repository is up to date.
• [x] Check that the README file is up-to-date.
• [x] Add and reference issues and PRs mentioned in the milestone to CHANGELOG.txt.
• [x] Bump the version in the metadata.txt file.
• [x] Check that all issues and PRs for the version number to release have been closed.
• [x] Create the zip package.
• [x] Test the zip package locally.
• [x] Upload the zip package to the QGIS Python Plugins Repository.
• [x] Tag a new release.
• [x] Close the issue named Prepare for GIS4WRF 0.14.2 release.

gis4wrf.zip

[letmaik]

@dmey I created the zip package and attached it. Could you give it a quick test and then upload it?

[dmey]

There are still issues with setting up the domain -- see qgis-tutorial-log.txt.

[letmaik]

We may want to consider doing a release anyway already since currently the plugin is broken on Windows on all QGIS versions due to #155. I think the domain/CRS issue is an upstream bug so could take a while: https://github.com/qgis/QGIS/issues/33519.

[dmey]

OK -- but I would prefer to handle the domain issue in some way. Restricting the version to 3.4 on all systems would be too much as on Linux and macOS there are not problems with newer versions. We could do an ad-hoc prompt on Windows but I don't think it's worth the effort. How about adding a check in the domain configuration for now and if custom CRS are required, we could prompt an informative message to users that there is currently a bug and that if they want to use such feature they need to use an older version on Windows?

[letmaik]

Ok let's do that then, it's easy enough to detect the failure when creating the custom CRS. Also, it's nothing to do with Windows as people have reported it on other systems. I think it's a QGIS bug introduced somewhere between 3.6 and 3.10.

[dmey]

It works fine in 3.6 so that would be after. Re this I am not sure -- as you have noted in https://github.com/GIS4WRF/gis4wrf/issues/149#issuecomment-568935812 there are some changes that the user would also need to do for example on Windows this would be deleting the C:\Users\<user>\AppData\Roaming\QGIS and C:\Users\<user>\AppData\Local\QGIS folders. So if a user has upgraded to the newer version they would also need to delete those profiles in order to fix this issue -- installing/downgrading to an older version will not be enough. Unfortunately these are not folders we want/can remove so unless there is something very specific to delete that we can take care programmatically, I think this will be a pain point for a number of users who later try to set up GIS4WRF.

[letmaik]

Given https://github.com/GIS4WRF/gis4wrf/issues/149#issuecomment-569264760 I think the best course of action is to detect the failure and if it happens tell the user to update to the latest QGIS (patch) version. It's not out yet unfortunately.

[letmaik]

I updated the zip package. Can you give it a try and upload to the registry if all is fine?

[dmey]

All good 👍 -- updated to https://plugins.qgis.org/plugins/gis4wrf/

[dmey]

The package