GeoStat-Framework / PyKrige

Kriging Toolkit for Python

https://pykrige.readthedocs.io

BSD 3-Clause "New" or "Revised" License

741 stars 186 forks source link

v1.5.0 #145

Closed MuellerSeb closed 4 years ago

MuellerSeb commented 4 years ago

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 (#125)
pre-build wheels for py35-py38 on Linux, Windows and MacOS (#142)
GridSerachCV from the compat module sets iid=False by default (if present in sklearn) to be future prove (iid will be deprecated) (#144)

Changes

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

MuellerSeb commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@rth see #146

bsmurphy commented 4 years ago

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