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