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
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
I'd like to put this out there for discussion.
yt-dev mailing list