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