Notes on versioning and PRs

[luizirber]

Goal: master branch is always released

Build system changes

• Auto tagging on new merges
  Part of the problem of doing new releases is that we need to tag and test
  the tag manually. Automate it!
• Build wheels on every tag
• Auto upload to PyPI
  • I think the auto bump bot in bioconda can pick up our new versions without we needing to open a new PR there Yup! Already works.
  • If we don't want to automate all the way, at least upload it to testpypi and check if it works

Checklist changes

I don't think we need to enforce it, but it would help whoever is merging to
have the PR submitter suggest what changes are being proposed. We can define
some broad categories based on conventional commits:

https://www.conventionalcommits.org/en/v1.0.0-beta.2/

Suggestion:

• patch: bugfixes, no new features or breaking changes in APIs. Version bump
  from x.x.1 to x.x.2.

• feature: minor version bump (x.0.0 to x.1.0).

• chore: updates to build system, no version change.

• doc: updates to documentation.

• BREAKING CHANGE: this is a major version bump (2.x.x to 3.0.0), and we would
  like to avoid this as much as possible (but we shouldn't be afraid of doing
  them!). Whenever we remove an API, or change how we call functions.

for doc and chore no version change is required, but may be good to
do a patch bump (x.x.1 to x.x.2) to keep with the goal of always have master
tagged and released.

Use more github templates

See https://github.com/datrs/hypercore/tree/master/.github for inspiration (I didn't even know it was possible to have multiple issue templates!)

Other changes

• Benchmarks! Extend benchmarks #128

• Since we have the WIP bot we don't need the [WIP] and [MRG] tags in the title
  anymore (we can put it in the PR description). This also avoids we merging
  things with [MRG] commit messages into master =P GitHub released 'draft PR', so I don't even think we need the [WIP] and [MRG] tags anymore

[luizirber]

The Julia release process
https://julialang.org/blog/2019/08/release-process

[luizirber]

Pandas deprecation policy: https://dev.pandas.io/docs/whatsnew/v1.0.0.html#new-deprecation-policy

[ctb]

https://twitter.com/adrinjalali/status/1442048926274801669

if_delegate_has_method is deprecated in @scikit_learn
1.0, and here's a good example of how to avoid deprecation warnings while supporting multiple #scikit_learn versions

I'm not 100% sure I understand this fully, but the magic seems to be here -

   if parse_version(sklearn.__version__) < parse_version("1.0.0"):
        from sklearn.utils.metaestimators import if_delegate_has_method
        return if_delegate_has_method(attr)
    else:
        from sklearn.utils.metaestimators import available_if
        return available_if(_estimator_has(attr))

which checks the scikit-learn version explicitly, and does different things depending on version.