scikit-learn-contrib / metric-learn

Metric learning algorithms in Python
http://contrib.scikit-learn.org/metric-learn/
MIT License
1.4k stars 234 forks source link

[DOC] Add developer documentation page #259

Open bellet opened 5 years ago

bellet commented 5 years ago

To make it easier for newcomers to start contributing to metric-learn, we should a developer page in the doc. This page should explain things like how to start contributing, how to compile the doc locally, etc. We could borrow ideas from https://scikit-learn.org/stable/developers/contributing.html

wdevazelhes commented 4 years ago

Here is a quick comment on what to do for a release (first draft, some things might be missing but I'll try to be inclusive):

Things to check before the release:

Release:

bellet commented 4 years ago

Thanks. For conda-forge there is not much to do, a PR is automatically created in the feedstock repo https://github.com/conda-forge/metric-learn-feedstock If requirements, license, etc have not changed, the recipe automatically generated by the bot should be correct. Otherwise one can edit it and directly push to the PR, see https://conda-forge.org/docs/maintainer/updating_pkgs.html Then merging the PR (which requires to be identified as a maintainer of the feedstock) will make the release. If it is not visible on https://anaconda.org/conda-forge/metric-learn One can do an empty commit to master to trigger the update

terrytangyuan commented 4 years ago

One suggestion: instead of releasing directly from master, we can consider doing the following:

  1. Create branch v0.1.0-release from master that includes all changes mentioned above, e.g. version number, etc.
  2. Turn this branch into protected branch.
  3. Create a release v0.1.0-rc0 ("rc" stands for release candidate) from this branch v0.1.0-release via GitHub UI here and mark it as pre-release.
  4. Give the community some time (e.g. 1-2 weeks) to test the release candidate.
  5. If there are any bug fixes, we push to v0.1.0-release branch and then release v0.1.0-rc1.
  6. Once we are confident, we create a stable release v0.1.0, build the package wheels, and then publish the package v0.1.0 to PyPI

If there are any critical bug fixes/patches, we can still cherry-pick and backport the changes to v0.1.0-release or any past release branches.