[yt-dev] RFC: Staggered deprecation through 3.1 and 3.2

[Matthew Turk]

Hi all,

One thing we really tried to do with 3.0 was break all the APIs we
thought we'd need to before release.  This included things like ds/pf,
index/hierarchy, the way data selections were made, etc.

It's starting to become clear that we are approaching maturity at
different rates in these initiatives.  I am wondering if perhaps we
should de-couple the release from all of the API breakages, and
instead note which interfaces we know are going to change in the
future.

Pragmatically, what this would mean is:

 * Release a 3.0 with the old VR and halo finding interfaces
 * Release a 3.1 with either the new VR or the new halo finding (or both)
 * Do the same for 3.2

This doesn't fit with the usual "major numbers are where APIs break"
philosophy that comes from semantic versioning, but I think from the
perspective of pragmatism, if we identify those sections of the code
that are *going* to change, and we pitch 3.0 as the first part of a
staged release of totally rewritten infrastructure, we can likely come
out okay.

I'd like to put this out there for discussion.

-Matt