<div>Ideally we would release yt 3.4 then merge in some of the backward incompatible changes Matt referred to. The "roll-out" would then be just the normal development process we've been following for a while. The development version of yt 4.0 would then just be the latest version on the yt branch in the repo.</div><div><br></div><div>We don't know how long the repo will be like this but I'd say there's a very good chance it will be longer than three months, likely closer to a year. Efforts like yours to update existing software will also be very helpful for us as it will allow us to find places where we need to add helpers to match functionality we used to have and that you need.</div><div><br></div><div>Hope that helps clear things up.</div><div><br></div><div>Nathan</div><div><br><div class="gmail_quote"><div>On Fri, Feb 24, 2017 at 5:47 AM Desika Narayanan <<a href="mailto:desika.narayanan@gmail.com">desika.narayanan@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_msg">Hey Matt,<div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Thanks for this update. This doesn't really answer any of your questions, but Is there a rough (i.e. +/- 3 months) time scale for a 4.0 roll out? And as that approaches, will there be a fork we can download and play with? For some SPH users like myself, this would allow me to on the side work on development for public software like powderday and try to start getting it 4.0 compatible in advance.</div></div><div class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">-d</div></div><div class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_extra gmail_msg"><br class="gmail_msg"><div class="gmail_quote gmail_msg">On Thu, Feb 23, 2017 at 4:17 PM, Matthew Turk <span class="gmail_msg"><<a href="mailto:matthewturk@gmail.com" class="gmail_msg" target="_blank">matthewturk@gmail.com</a>></span> wrote:<br class="gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi folks,<br class="gmail_msg">
<br class="gmail_msg">
There are a couple big, backwards-incompatible changes that are coming<br class="gmail_msg">
up in the future for yt. None of these will come as a surprise, but<br class="gmail_msg">
here they are:<br class="gmail_msg">
<br class="gmail_msg">
* The Demeshening: removing the global octree index for particle<br class="gmail_msg">
datasets and replacing with a bitmap index. This also includes<br class="gmail_msg">
changing how particle fields are regarded, and makes the SPH<br class="gmail_msg">
implementation much cleaner and faster.<br class="gmail_msg">
* Non-Spatial Coordinates: this one is a bit different than the title<br class="gmail_msg">
suggests. For example, ds.domain_left_edge and ds.domain_right_edge<br class="gmail_msg">
will no longer be YTArray instances, instead they will be YTIndexArray<br class="gmail_msg">
instances. YTIndexArray differs from YTArray in that instead of having<br class="gmail_msg">
a single unit associated with it, it has a tuple of units, one for<br class="gmail_msg">
each column of the array. This will not, in its initial form, be a<br class="gmail_msg">
big change to non-Cartesian coordinates, but that will certainly be<br class="gmail_msg">
possible.<br class="gmail_msg">
<br class="gmail_msg">
YTEPs are either done or being prepped for both of these. Those are<br class="gmail_msg">
kind of outside the main topic of this email, which is much more<br class="gmail_msg">
social.<br class="gmail_msg">
<br class="gmail_msg">
>From discussions, it seems pretty likely that these two would need to<br class="gmail_msg">
be a yt 4.0. So let's take that as a given.<br class="gmail_msg">
<br class="gmail_msg">
Both of these are designed to be *as backwards compatible as<br class="gmail_msg">
possible*. The Demeshening will have many more breaking changes for<br class="gmail_msg">
people that rely on yt for SPH data, but ideally the *surface area* of<br class="gmail_msg">
those breakages will be small. For the non-spatial changes, we<br class="gmail_msg">
absolutely want that to be completely backwards compatible for<br class="gmail_msg">
cartesian, spatial datasets.<br class="gmail_msg">
<br class="gmail_msg">
So if we take as given that we want disruption to both users and<br class="gmail_msg">
developers to be minimal, we're still kind of stuck with the<br class="gmail_msg">
possibility that this will be a difficult transition. We absolutely<br class="gmail_msg">
want everything that worked before to work again.<br class="gmail_msg">
<br class="gmail_msg">
What I'm getting at is this: how can we manage this change, when the<br class="gmail_msg">
development from 3.x to 4.0 may be long? We're at a different stage<br class="gmail_msg">
than we were when we managed this for yt 3.0, which I did *not* do a<br class="gmail_msg">
good job of managing. We now encourage people to use binary<br class="gmail_msg">
distributions a lot more, and we have a reliable bugfix release<br class="gmail_msg">
system.<br class="gmail_msg">
<br class="gmail_msg">
If we were to merge in both of those two big things, there is still<br class="gmail_msg">
the possibility that unforeseen difficulties would crop up -- but, the<br class="gmail_msg">
userbase will be much more isolated than they were when we did 3.0.<br class="gmail_msg">
So the main problem is going to be if folks want to do big<br class="gmail_msg">
development, but that big development conflicts with one of those two<br class="gmail_msg">
things.<br class="gmail_msg">
<br class="gmail_msg">
Here's the first thing I want to ask:<br class="gmail_msg">
<br class="gmail_msg">
==<br class="gmail_msg">
Is anybody planning or working toward some big development that they<br class="gmail_msg">
would be nervous about doing in the codebase while we shake out any<br class="gmail_msg">
lingering issues from those?<br class="gmail_msg">
==<br class="gmail_msg">
<br class="gmail_msg">
Ultimately, the question we need to figure out is, "how do we minimize<br class="gmail_msg">
disruption to cartesian, grid-based codes while we fix this stuff up?"<br class="gmail_msg">
And I think until we know if folks have anything pretty big planned,<br class="gmail_msg">
we can't *quite* answer that.<br class="gmail_msg">
<br class="gmail_msg">
-Matt<br class="gmail_msg">
_______________________________________________<br class="gmail_msg">
yt-dev mailing list<br class="gmail_msg">
<a href="mailto:yt-dev@lists.spacepope.org" class="gmail_msg" target="_blank">yt-dev@lists.spacepope.org</a><br class="gmail_msg">
<a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" rel="noreferrer" class="gmail_msg" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br class="gmail_msg">
</blockquote></div><br class="gmail_msg"></div></div>
_______________________________________________<br class="gmail_msg">
yt-dev mailing list<br class="gmail_msg">
<a href="mailto:yt-dev@lists.spacepope.org" class="gmail_msg" target="_blank">yt-dev@lists.spacepope.org</a><br class="gmail_msg">
<a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" rel="noreferrer" class="gmail_msg" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br class="gmail_msg">
</blockquote></div></div>