Matt,
On Tue, Oct 1, 2013 at 12:50 PM, Matthew Turk
* 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