[scikit-image] A request for more frequent releases

[Stefan van der Walt]

On Tue, 11 Sep 2018 23:16:29 +0300, Egor Panfilov wrote:
> - For the release cycle, I'd, however, agree with you only partially. From
> my standpoint, having weekly/bi-weekly/montly releases (a) is too expensive
> in terms of workforce, (b) discounts the release value and significantly
> reduces their noticeability, and (c) doesn't really make a lot of sense. In
> my experience, every 4 weeks only a very little number of significant PRs
> are developed and merged. Having said that, I believe, a reasonable cycle
> would be something like 1 release / 2-3 months. Once we see a progression
> in the contribution activity, we can consider discussing further changes in
> the schedule.

In an ideal world, we would be ready to punch out a release at a day's
notice, but would probably only release every three months or so.  A
release is not merely a tagging of the current master, but also a
statement about the readiness of the code it contains.  E.g., we are
more lenient about merging experimental features early on in the release
cycle, and sometimes modify or even remove APIs that we feel are not
mature enough.

Mark, I wonder if some of your issues can be addressed by daily wheel
builds (which we already have)?  Then you can point pip to our Rackspace
wheels container, and install from there.

The 32-bit issues mentioned were long known, because Matthew builds for
that platform daily, and reported the failures a long time ago.  It has
not been fixed because no one has taken the time to investigate
thoroughly (perhaps not that many developers care about 64-bit?).

I fully support attempts to reduce the burden of turning `master` into a
release.

One such a proposed change was versioneer, but I recall from Mark's
previous PR (https://github.com/scikit-image/scikit-image/issues/3144)
that it introduced quite a bit of complexity for little gain.  I'm not
sure why the current versioning is considered troublesome; it is stored
in `skimage/__init__.py`, and is reused everywhere else.

W.r.t. listing new features for a release, Nathaniel's suggestion of
Towncrier looks sensible, and helps to avoid conflicts.  On the other
hand, the more tools we use, the higher the overhead to contributing.
So, is it really a big problem to update the relevant text files?  If
that process is not documented clearly enough, that is something we can
address right now.

W.r.t. adding the wheel building machinery into the skimage source repo,
I'm not sure I see how that would be useful, or why that would be a good
fit.

W.r.t. backports to 0.14.x—since we no longer support 2.7 on master,
this really is the only way to give 2.7 users access to new features.
When a backport is easy to do, what motivation do we have for witholding
it?

Thanks for your thoughts!
Stéfan