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

Cameron Hummels chummels at gmail.com
Tue Oct 1 13:13:43 PDT 2013


It was my understanding (but I have not tested this personally) that
several of the recipes in the cookbook could not yet be reproduced in 3.x.
 Is this true?  If so, is the idea for 2.6 to be the last major version of
2.x and then all development to be shifted to 3.0, and part of this early
3.0 development would be on making sure that all of the functionality from
2.x work in 3.x?

I very much understand your statement of being in a perpetual state of
never-yet-ready, but I think before we push more and more people to the 3.x
branch, we need to make sure all the major pieces of functionality (mostly
demonstrated through cookbook recipes) works in 3.x.  This shiftover from
2.x to 3.x could, in fact, be the major facilitator of this, I just want to
confirm the status of things.  If that's the case, then I'm in favor of
this.

Cameron


On Tue, Oct 1, 2013 at 1:06 PM, Nathan Goldbaum <nathan12343 at gmail.com>wrote:

> Matt,
>
> On Tue, Oct 1, 2013 at 12:50 PM, Matthew Turk <matthewturk at 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 at lists.spacepope.org
>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>
>
>
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
>


-- 
Cameron Hummels
Postdoctoral Researcher
Steward Observatory
University of Arizona
http://chummels.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20131001/38c97a4e/attachment.htm>


More information about the yt-dev mailing list