Matt,

On Tue, Oct 1, 2013 at 12:50 PM, Matthew Turk <matthewturk@gmail.com> wrote:
 * 2.6 be released on November 1, 2013, which gives several days after
the "doc sprint."  I will be working on docs leading up to the doc
sprint.  The code is in a good state at this point and we can release
it at any time, but the documentation is the primary blocker for 2.6.
 * I have added three maintenance releases, every three months, for
2.6.1, 2.6.2, 2.6.3 and 2.6.4.  This is because will *not* be
deprecating the 2.x series.

How will this work inside the repo?  Will be using branches and a single 
repository?  Will we accept pull requests into the 2.X codebase or only 
accept PRs for 3.X and then backport as appropriate?
 
 * 3.0 has been added with a tentative release on January 1, 2014.  I
have assessed the reliability of the code, and it seems to me that
*even as it is*, it is considerably better than the 2.x line of
development.  The remaining struggles are all in documentation.  A
handful of operations are still outstanding -- clump finding and
boolean objects most notably -- but the vast, vast majority are
implemented.


I also think it's important to address these two issues:

https://bitbucket.org/yt_analysis/yt/issue/552/cut_region-doesnt-work-in-30
https://bitbucket.org/yt_analysis/yt/issue/499/missing-hierarchy-functions
 
I'd like to resolve this by proposing we wind down development on 2.X
as best we can, and instead attempt to focus resources on 3.0.  Until
we do that, the biggest fish of the refactor/redesign simply can't
land, which means we're in a self-perpetuating cycle of never getting
to the point of being "ready."

Agreed!  I'm excited for everything to move over the 3.0 - it will be a relief 
to make changes without having to worry about future merge conflicts.
 

-Matt
_______________________________________________
yt-dev mailing list
yt-dev@lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org