[yt-dev] Proposed: release dates for 2.6, 2.6.x, and 3.0

Matthew Turk matthewturk at gmail.com
Tue Oct 1 12:50:55 PDT 2013


Hi all,

I have issued a pull request which needs to be discussed; I'd rather
that be here as it's a more central location.

https://bitbucket.org/yt_analysis/ytep/pull-request/26/proposing-release-dates-for-26-26x-and-30/diff

I would like to propose:

 * 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.
 * 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 have one other reason I want to push for a release: I would like to
diverge the two lines of development in some substantial ways, and I
do not think we can do that until we have a clear end-game.  These
ways are all enumerated in these two YTEPs:

https://ytep.readthedocs.org/en/latest/YTEPs/YTEP-0003.html (by Casey)
https://bitbucket.org/yt_analysis/ytep/pull-request/25/ytep-0017-de-astroifying-yt-a-bit-and
(by me, not yet accepted)

Both of these actually have commits outstanding, but which we have
been reluctant to merge into mainline 3.0 because they will make
future merging *into* 3.0 quite difficult.  They also both break
backwards compat, and before we get *any* more uptake of 3.0 than we
already have, I'd like to merge them in.

<bold for emphasis!>
An unavoidable requirement for these two YTEPs to be merged in is that
a 3.0 documentation build must exist and must be up to date.  This is
*my* responsibility, and I have begun to undertake it.
<unbold>

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."

-Matt



More information about the yt-dev mailing list