[scikit-image] A request for more frequent releases

[Mark Harfouche]

Hi All,

I would like to request that scikit-image work toward a much more frequent
release cycle.
Let me give some anecdotal reasons why this might be a good idea.

As a new contributor, scikit-image has given me a few things:
1. It has taught me a lot about some best practices with respect to
software development.
2. It has given me "free" reviews of software and features I would like to
implement with respect to image processing.
3. It has taught me a lot about releasing software in a systematic manner.
4. Once code that I depend on is included in scikit-image, it likely gets
tests and maintained much better than code I would write on my own. Lately,
two good examples have been Python 3.7 and numpy 1.15 compatibility.

Of course, now that I know a little more about collaborative software
development, I try to give back.

Unfortunately, as you all know, contributing doesn't come for free.

With the long time lag between releases, writing code or bug fixes for
scikit-image means that I have to replicate them for my own projects.
My current workaround has converged to having a subdirectory
`upstream/skimage` where I hold a few bug fixes that I have come to rely on
from the `master` branch of `scikit-image`.
Not only is that costly, but refactoring my code after scikit-image will
get a release will also be costly. As such, I now have a disincentive to
submit patches, bug reports, speedups to scikit-image.
Having my own `upstream/skimage` directory means that I will likely diverge
from scikit-image's best practices when I implement my own functions.

This is going to make it harder and harder to find time to contribute back
to scikit-image as the complexity of my projects grows. Not contributing to
scikit-image will come at some cost to me, but I would like to emphasize
that I am likely not the only one that is probably facing these dilemmas.
This means that whatever code I or others like me develop, be it for
speeding up warping, or image registration on cuda (to name two features I
am working on), will likely not make it to scikit-image if the cost of
contributing stays high.

Currently, asking for a 2-week release cycle is guaranteed to be rejected.

The Release guidelines are 125 lines long (if we ignore the Debian and
conda-forge instructions).
https://github.com/scikit-image/scikit-image/blob/master/RELEASE.txt

  - Many files need to be renamed. This can be done on an automated script.
  - Docs need to be rebuilt and uploaded. We can work to do this with
travis deploy, or readthedocs
  - Release notes need to be manually scanned. We can ask for this to be
done in each PR.
  - Updating __version__ is a pain. I really suggest we work toward using
versioneer and tags instead of branches for releases.
  - Building wheels is done in separate repo. I really suggest we merge
scikit-image-wheels into scikit-image itself and build wheels on every PR.
  - conda-forge now has automated scripts that will bump the version
number. This should be moved out as these instructions are stale and
available on the feedstock itself.
  - Debian can release however often they like.

Asking for release notes to be updated in PRs will cause conflicts in PRs.
I think this is a feature, not a bug. Many times tests are failing because
of typos in small changes in the code. Asking for an updated rebase will
help us ensure real time code correctness.

I am more than glad to help work on any of the points I mentioned above and
any others you find necessary.

I know this will take work, but I think having much more frequent releases,
timed releases, will help ensure that people can rely on their
contributions making it to PyPi or conda-forge so that they can ask others
to rely on them.

Thank you very much for considering this,

Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20180909/fba769d1/attachment.html>