<div dir="ltr">I was under the impression that yt-3.0 development was already being done in the yt_analysis/yt repository.  There is definitely a yt-3.0 branch in there.  Is it not being used?  If not, I don't think a strong case can be made for people trying it until then.<div>
<br></div><div>On the branch naming question, if we were to merge yt-3.0 development into the yt branch, what would happen to the yt-3.0 branch?  Since branches are forever in hg, it will always be hanging around.</div><div>
<br></div><div>Finally, I've said this before to a few people and it's been touched on in this thread, but I don't think the main hangup for a 3.0 release is the code, but the documentation.  Unless I am mistaken, there is effectively no documentation of what has changed between 2.x and 3.0.  This needs to be near the top of the priority list for organizing for a release.</div>
<div><br></div><div>Britton</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Oct 4, 2013 at 6:19 PM, Matthew Turk <span dir="ltr"><<a href="mailto:matthewturk@gmail.com" target="_blank">matthewturk@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
A corrollary of this is: when should the yt-3.0 branch development be<br>
moved primarily into the main yt_analysis/yt repository.  This is not<br>
the same as making it the main or stable line.<br>
<br>
Upsides: easier to switch between mainline and 3.0, easier to do<br>
releases, and easier for people out there to switch and to update.<br>
Downsides: higher turnover in relatively large ways on our main<br>
repository, although outside of the main branch, and there are a<br>
number of extant forks of 3.0 already that would be orphaned.<br>
<br>
I'm probably fine with this happening soon, I think.  The YTEP<br>
suggests a release date for 3.0a4 of October 15, but I'd be fine<br>
pushing the yt-3.0 branch into yt_analysis/yt anytime.  It's unlikely<br>
that someone who doesn't want 3.0 would blindly update to 3.0 if "tip"<br>
is in 3.0, so I don't think that's a huge concern.<br>
<br>
-Matt<br>
<div class="HOEnZb"><div class="h5"><br>
On Tue, Oct 1, 2013 at 3:50 PM, Matthew Turk <<a href="mailto:matthewturk@gmail.com">matthewturk@gmail.com</a>> wrote:<br>
> Hi all,<br>
><br>
> I have issued a pull request which needs to be discussed; I'd rather<br>
> that be here as it's a more central location.<br>
><br>
> <a href="https://bitbucket.org/yt_analysis/ytep/pull-request/26/proposing-release-dates-for-26-26x-and-30/diff" target="_blank">https://bitbucket.org/yt_analysis/ytep/pull-request/26/proposing-release-dates-for-26-26x-and-30/diff</a><br>

><br>
> I would like to propose:<br>
><br>
>  * 2.6 be released on November 1, 2013, which gives several days after<br>
> the "doc sprint."  I will be working on docs leading up to the doc<br>
> sprint.  The code is in a good state at this point and we can release<br>
> it at any time, but the documentation is the primary blocker for 2.6.<br>
>  * I have added three maintenance releases, every three months, for<br>
> 2.6.1, 2.6.2, 2.6.3 and 2.6.4.  This is because will *not* be<br>
> deprecating the 2.x series.<br>
>  * 3.0 has been added with a tentative release on January 1, 2014.  I<br>
> have assessed the reliability of the code, and it seems to me that<br>
> *even as it is*, it is considerably better than the 2.x line of<br>
> development.  The remaining struggles are all in documentation.  A<br>
> handful of operations are still outstanding -- clump finding and<br>
> boolean objects most notably -- but the vast, vast majority are<br>
> implemented.<br>
><br>
> I have one other reason I want to push for a release: I would like to<br>
> diverge the two lines of development in some substantial ways, and I<br>
> do not think we can do that until we have a clear end-game.  These<br>
> ways are all enumerated in these two YTEPs:<br>
><br>
> <a href="https://ytep.readthedocs.org/en/latest/YTEPs/YTEP-0003.html" target="_blank">https://ytep.readthedocs.org/en/latest/YTEPs/YTEP-0003.html</a> (by Casey)<br>
> <a href="https://bitbucket.org/yt_analysis/ytep/pull-request/25/ytep-0017-de-astroifying-yt-a-bit-and" target="_blank">https://bitbucket.org/yt_analysis/ytep/pull-request/25/ytep-0017-de-astroifying-yt-a-bit-and</a><br>

> (by me, not yet accepted)<br>
><br>
> Both of these actually have commits outstanding, but which we have<br>
> been reluctant to merge into mainline 3.0 because they will make<br>
> future merging *into* 3.0 quite difficult.  They also both break<br>
> backwards compat, and before we get *any* more uptake of 3.0 than we<br>
> already have, I'd like to merge them in.<br>
><br>
> <bold for emphasis!><br>
> An unavoidable requirement for these two YTEPs to be merged in is that<br>
> a 3.0 documentation build must exist and must be up to date.  This is<br>
> *my* responsibility, and I have begun to undertake it.<br>
> <unbold><br>
><br>
> I'd like to resolve this by proposing we wind down development on 2.X<br>
> as best we can, and instead attempt to focus resources on 3.0.  Until<br>
> we do that, the biggest fish of the refactor/redesign simply can't<br>
> land, which means we're in a self-perpetuating cycle of never getting<br>
> to the point of being "ready."<br>
><br>
> -Matt<br>
_______________________________________________<br>
yt-dev mailing list<br>
<a href="mailto:yt-dev@lists.spacepope.org">yt-dev@lists.spacepope.org</a><br>
<a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
</div></div></blockquote></div><br></div>