Could holoviz adopt more of a "release early, release often" approach for conda-forge?

[rsignell-usgs]

@jbednar, I'm going to be giving a Pangeo tutorial next week at the Integrated Ocean Observing System code sprint in Ann Arbor for about 40 people, and several notebooks with HoloViz tools will be featured.

Currently the environment.yml to get the needed HoloViz functionality looks like this:

 channels:
  - conda-forge
dependencies:
  - cartopy
  - fsspec
  - pyviz/label/dev::hvplot
  - pyviz/label/dev::holoviews
  - pyviz/label/dev::panel
  - pyviz/label/dev::datashader
  - metpy
  - numpy
  - xarray
  - pip
  - pip:
    - git+https://github.com/pyviz/geoviews.git

Obviously getting a bunch of stuff from dev channels and geoviews from master does not exactly convey confidence to HoloViz newcomers.

I realize that all these packages change rapidly and have inter-dependencies, but could a "release often, release early" approach with the standard conda-forge channel be adopted as a solution? Are the released packages really that much more stable than the dev channel packages?

@ocefpaf has long advocated for this approach, and I think it would really help boost community use of the HoloViz suite.

[philippjfr]

The interdependencies are certainly part of the problem. That said for most of our packages we have switched to a much more regular release schedule, with new minor HoloViews and Panel releases being cut every 1-2 months. hvPlot has been kind of a sad exception to that rule as my focus was shifted from hvPlot maintenance to Panel development.

That said we have been clearing the backlog of issues on hvPlot, in large part due to @jsignell's help and are currently gearing up to a coordinated release of datashader, HoloViews, GeoViews and hvPlot. Having caught up on some of the backlog I think we are now in a much better place than we were and are not planning on releasing any major changes that have to be coordinated across our entire stack.

I very much take your point to heart though and we will try to set up a regular release schedule. Often times I end up trying to clear a backlog, which ends up pushing the release date further and further out, instead we should just stick to a more regular schedule to release often and early.

[rsignell-usgs]

@philippjfr , that would be great!
( It would help prevent messes like this: intake/xrviz#46 (comment))

[jbednar]

At least for Datashader, having more frequent releases has been difficult because of the manual build steps required for the website, which was too large and required fetching too-big datasets for Travis to build in its entirety. After Julia's work over the past couple of months and completing last week, we've now been able to automate Datashader releases by moving all the difficult-to-build examples into examples.pyviz.org, where they are pinned and built individually in a way that doesn't need to hold back any library's releases. Datashader releases have often been needed for related projects like HoloViews that depend on new Datashader features or fixes, which should no longer have to happen.

I think all our projects are now releasable by simply tagging, so having a more regular release cadence should now be feasible for us. I propose that we move to a calendar-based triage and release schedule, expecting to have at least one (rotating) person go through the open issues and deal with what can be dealt with on a set schedule, with a release of the main projects expected thereafter (or an explicit decision that there is no functionality ready that needs a release). Sound ok, @jlstevens , @jsignell , and @philippjfr ?

[maximlt]

The release schedule of the HoloViz packages has probably got better over time, hvPlot was I think lagging a bit behind Panel and HoloViews but I intend to release it more frequently.