On 24 Jun 2014 17:38, "Matthew Turk" <matthewturk@gmail.com> wrote:

I think Britton covered the halos, but the VR works as-is.  As far as
3.0beta, I'm a bit nervous about that as we want to avoid the
situation where we are in beta for 1+ years... I am worried about the
perception of a "beta" tag.  Is that overblown?  Would calling it
"yt-3.0-2014" work?

On Tue, Jun 24, 2014 at 10:32 AM, Nathan Goldbaum <nathan12343@gmail.com> wrote:
> Do the old VR and halo interfaces work?  Not much effort has gone into
> porting them, I think.
>
>
> On Tuesday, June 24, 2014, Sam Skillman <samskillman@gmail.com> wrote:
>>
>> 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@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@lists.spacepope.org
>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>
>>
>
> _______________________________________________
> yt-dev mailing list
> yt-dev@lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
_______________________________________________
yt-dev mailing list
yt-dev@lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org