Hey yt,
I realize I am being fairly selfish here, but I think that it would be great if there was a stable yt-3.0 that was the yt. My personal opinion is that it is stable enough.
I don't expect this to happen tomorrow. But I don't think that the end of the year would be an unreasonable target.
Matt seemed amicable to the idea when we talked about it yesterday. Still, I thought I would throw this out there for folks to give feedback on.
Be Well Anthony
Hi Anthony,
My impression is that there are still a number of analysis modules that haven't been ported over to yt-3.0. Some of these are on my own to-do list, such as the halo profiler. I'm not sure what they all are or if most of them even need to be changed at all, but I guess a standard we might want to go by is whether all of the existing cookbook recipes work with yt-3.0. We could do a release without them, but we would need to be clear to users that certain functionality is unavailable.
Britton
On Mon, Sep 23, 2013 at 5:56 AM, Anthony Scopatz scopatz@gmail.com wrote:
Hey yt,
I realize I am being fairly selfish here, but I think that it would be great if there was a stable yt-3.0 that was the yt. My personal opinion is that it is stable enough.
I don't expect this to happen tomorrow. But I don't think that the end of the year would be an unreasonable target.
Matt seemed amicable to the idea when we talked about it yesterday. Still, I thought I would throw this out there for folks to give feedback on.
Be Well Anthony
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Hi Anthony,
Let me start out by saying, I have a tendency to put off this type of thing, so thank you for bringing it up.
On Mon, Sep 23, 2013 at 12:56 AM, Anthony Scopatz scopatz@gmail.com wrote:
Hey yt,
I realize I am being fairly selfish here, but I think that it would be great if there was a stable yt-3.0 that was the yt. My personal opinion is that it is stable enough.
I agree with this.
>
I don't expect this to happen tomorrow. But I don't think that the end of the year would be an unreasonable target.
Matt seemed amicable to the idea when we talked about it yesterday. Still, I thought I would throw this out there for folks to give feedback on.
Britton's point is good, that not everything has been ported; there are a few major things that I can think of. This includes clump finding, several of the frontends, and boolean objects. I think I know how to do all of these, they just need time.
And, there is the bigger problem of having created a list of features that 3.0 was to have and not getting all of them implemented. Units is the biggest one, but that can be added later. These can basically be divided into a few categories:
- Things that break backwards compat and so need to be implemented before a "release"
- Things we'd like but that don't break backwards compat and so can be added later
That all being said, "perfect is the enemy of good enough." Since the 2.X series will be a long-term support branch, I think if we can finish up ripping bandaids off, we should try for a 3.0 release by the end of the year. That puts the following things on the critical path:
- Documentation, which means both a cheat sheet of what is new as well as a bunch of explanations of what has changed under the hood. Much of this will fall to me.
- Porting remaining frontends to 3.0, which unfortunately also means pushing hard on the patch-IO refactor.
- Field renaming, which currently is caught up in the units refactor. Units likely won't be done until 3.1 or 3.11 (yt for workgroups) so we may need to cherry pick these changes out. (I worked on units last week, though, and it may not be as far off as that.)
There are a few YTEPs as well that need to be implemented and tested:
https://bitbucket.org/yt_analysis/ytep/pull-request/25/ytep-0017-de-astroify... https://bitbucket.org/yt_analysis/ytep/pull-request/24/ytep-0018-reducing-di...
So if we summarize these, it comes down to:
- Ripping off bandaids for API changes.
- Documenting.
I think a 3.0 by the new year is feasible, but only if we can finish both of those, and only if we allow that not everything will be finished by then.
-Matt
>
Be Well Anthony
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-
Anthony Scopatz -
Britton Smith -
Matthew Turk