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