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

[Matthew Turk]

That's the one -- you mentioned it in a blockers email a few days ago.

On Tue, Jun 24, 2014 at 12:06 PM, Nathan Goldbaum <nathan12343 at gmail.com> wrote:
> Sorry - not sure which issue you're talking about - this one maybe?
>
> https://bitbucket.org/yt_analysis/yt/issue/827/enzo-particle-fields-work-differently-than
>
>
>
>
> On Tue, Jun 24, 2014 at 10:02 AM, Matthew Turk <matthewturk at gmail.com>
> wrote:
>>
>> Related to that, do you have a reproducible script for the particle
>> issue you reported?  If so, could you add that to either an issue or a
>> trello card so I can work on it?
>>
>> On Tue, Jun 24, 2014 at 11:58 AM, Nathan Goldbaum <nathan12343 at gmail.com>
>> wrote:
>> > 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 at 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 at nasa.gov
>> >> jzuhone at gmail.com
>> >>
>> >> > On Jun 24, 2014, at 12:38 PM, Matthew Turk <matthewturk at 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 at 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 at 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 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
>> >> >>
>> >> >> _______________________________________________
>> >> >> yt-dev mailing list
>> >> >> yt-dev at lists.spacepope.org
>> >> >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>> >> > _______________________________________________
>> >> > yt-dev mailing list
>> >> > yt-dev at lists.spacepope.org
>> >> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>> >> _______________________________________________
>> >> yt-dev mailing list
>> >> yt-dev at lists.spacepope.org
>> >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>> >
>> >
>> >
>> > _______________________________________________
>> > yt-dev mailing list
>> > yt-dev at lists.spacepope.org
>> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>> >
>> _______________________________________________
>> yt-dev mailing list
>> yt-dev at lists.spacepope.org
>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
>
>
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>