v1.5.0

[MuellerSeb]

This is the PR for the v1.5.0 release.

I just created a release candidate:
https://github.com/GeoStat-Framework/PyKrige/releases/tag/v1.5.0rc1

You can test it by installing:

pip install pykrige==1.5.0rc1

If you think there is still something missing, we can collect it here.

Release Notes

Installation

You can install pykrige with pip:

pip install pykrige

Documentation

The documentation can be found at: https://pykrige.readthedocs.io/

What's new?

New features

• support for GSTools covariance models (GSTools covariance model as variogram_model input #125)
• pre-build wheels for py35-py38 on Linux, Windows and MacOS (CI, Build and DOC updates #142)
• GridSerachCV from the compat module sets iid=False by default (if present in sklearn)
  to be future prove (iid will be deprecated) (Codeformatting with black #144)

Changes

• dropped py2* and py<3.5 support (CI, Build and DOC updates #142)
• installation now requires cython (CI, Build and DOC updates #142)
• codebase was formatted with black (Codeformatting with black #144)
• internally use of scipys lapack/blas bindings (CI, Build and DOC updates #142)
• PyKrige is now part of the GeoStat-Framework

[MuellerSeb]

From now on, there is also a Zenodo DOI for each release on Github:
https://zenodo.org/record/3738605

Do we want to include everyone as Author? If you give me your ORCID, I could create a .zenodo.json to automate the meta data. See here for example: https://github.com/GeoStat-Framework/GSTools/blob/master/.zenodo.json

[rth]

Do we want to include everyone as Author?

Since there are ~10 contributors I think that's manageable.

Generally I think it's easier to develop on the master branch, and create release branches (e.g. v1.5.X) + tag for releases, as opposed to have a develop branch and sync between master and develop. That way users are more encouraged to look at most up to date code if they look on github. That's what numpy, scipy, pandas etc are doing.

I haven't reviewed in detail but since it's only a sync between branches LGTM.

Thanks for working on it.

[MuellerSeb]

OK, I will create a zenodo file with appropriate meta data containing all authors (maintainers) and contributors.

ATM I am following this workflow (skipping release branches, since development is not that rapid):

I like the idea, that master always shows the latest release.

[rth]

ATM I am following this workflow (skipping release branches, since development is not that rapid):

Yeah, that's git flow, I think trunk based development is easier (cf. e.g. https://hackernoon.com/trunk-based-development-vs-git-flow-b1b23044dfb and https://stackoverflow.com/a/35915110/1791279) and that's what scipy ecosystem generally does. But I agree it's a never ending discussion topic.

[MuellerSeb]

Merging now. Thanks to all.
@rth I will update the conda-forge feedstock, but you will have to merge it, since you are the only maintainer ATM.

[rth]

I will update the conda-forge feedstock, but you will have to merge it, since you are the only maintainer ATM.

No need to make a release PR, one should be made automatically by a bot once you push the release on PyPi. Please make a PR to add yourself to maintainers in meta.yaml there.

[MuellerSeb]

@rth see #146

[bsmurphy]

Sorry again for the slow response here, but this all looks good. Thanks for the good work @MuellerSeb and @rth