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

[Sam Skillman]

I'm +1 on this, particularly since I'm at fault for not pushing on the VR
as much as I'd like to.


On Tue, Jun 24, 2014 at 7:44 AM, Matthew Turk <matthewturk at gmail.com> wrote:

> 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
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20140624/525c8eb0/attachment.html>