[yt-dev] Near- and mid-term roadmap: 2.4, 2.x, 3.0

[Matthew Turk]

Hi all,

Sam and I are working on issuing a PR about the volume rendering
refactor.  This is the last major code change to go in place for 2.4,
pending the quad_proj changes being accepted or rejected.  I'm still
thinking about this refine_by issue, and that might also make it in.
After the volume_refactor, it's just testing and documentation left:

https://bitbucket.org/yt_analysis/yt/issues?status=new&status=open&milestone=2.4

After 2.4 is released, I am going to shift my new development
exclusively to the yt-3.0 branch, which is currently hosted here:

http://bitbucket.org/yt_analysis/yt-3.0

This will include geometry refactoring and many remaining
de-Enzoifications of the code base.  3.0 is nearing a usable state,
but will not be ready for production for a while.  However, I think
that allowing the codebases to diverge too rapidly will lead to
problems: a fracturing.  So once the 3.0 codebase can muster feature
parity with 2.x, I am going to ask that all development on the 2.x
branch cease, and all pull requests for features and new functionality
be applied only to the 3.0 branch.  In advance of this, I would like
to solicit help: we've identified a number of relatively
straightforward changes to this code base that can and should be made.
 For instance, the changing of field names.  I'd also like to consider
moving to a more spread-out source code layout, like one class per
file.  Changes like these make it difficult to do cross-branch merges
and transplants, which is why I would like to save them for after
feature parity has been reached and development on 2.x has halted.

Previous threads:

http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/2012-February/001852.html
http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/2012-February/001868.html
http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/2012-February/001830.html
http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/2012-March/001941.html
http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/2012-March/001949.html

If anyone has any strong objections to this strategy, please reply.

Estimated Timeline:

 * June 26, 2.4 release
 * July 30, 3.0 reaches rough feature parity
 * Fall sometime: 3.0 merged into main 'yt' branch
 * Some time after that: 3.0 released

Criteria for Feature Parity:

 * All patch-based AMR codes support data region selection
 * Parallelism is functional for all parallel-capable routines
 * All patch-based AMR codes support projections, slices, cutting planes
 * All patch-based AMR codes support volume rendering
 * All patch-based AMR codes support halo finding
 * Octree-based AMR codes (RAMSES and ART) support data region selection
 * Octree-based AMR codes (RAMSES and ART) support slices, projections
and cutting planes

If any of you are interested in helping with this reengineering
effort, I would be extremely interested in collaborating.  My goal for
this effort is to focus on making yt a future-compatible code, and
changing it from an organically grown system into one that we design
based on the years of experience we all have now had with it.

-Matt