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

Nathan Goldbaum nathan12343 at gmail.com
Tue Jun 24 10:08:44 PDT 2014


Ok - I think the script in the issue description is sufficient.  Let me
know if you need something more detailed.


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

> 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
> >
> _______________________________________________
> 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/9a6d7e0c/attachment.htm>


More information about the yt-dev mailing list