I'd be +1 on this plan, although we should note that this is the plan in the release announcement.  We may also want to note that there are some issues with volume rendering of oct and particle data at the moment (I believe that's the case - let me know if I'm wrong there).

I think that leaves analysis modules and documentation as the main blockers for a 3.0 release.

-Nathan


On Tue, Jun 24, 2014 at 9:53 AM, John ZuHone <jzuhone@gmail.com> wrote:
+1 on Matt's proposal. -1 on a beta.

My worry about a beta release is that it will slow adoption, whether rightly or wrongly. I think we agree that we're ready to encourage adoption of 3.0.

John ZuHone
Laboratory for High-Energy Astrophysics
NASA/Goddard Space Flight Center
8800 Greenbelt Rd., Mail Code 662
Greenbelt, MD 20771
(w) 301-286-2531
(m) 781-708-5004
john.zuhone@nasa.gov
jzuhone@gmail.com

> On Jun 24, 2014, at 12:38 PM, 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
_______________________________________________
yt-dev mailing list
yt-dev@lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org