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

[Matthew Turk]

On Tue, Oct 1, 2013 at 4:13 PM, Cameron Hummels <chummels at gmail.com> wrote:
> 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?

There are two aspects to this.

1) The recipes will not work once the YTEPs have been merged.  They
will all need to be updated, since while I do intend to have a
compatibility layer as a requirement for the merging of those two big
things, the cookbook recipes will not be using the compatibility
layer.
2) The cookbook recipes, other than the boolean and cut regions which
I previously noted are not working, all work as of the PR I just
issued.

Additionally, I would classify updating the documentation and
cookbooks as part of the "bolded for emphasis" comments in my previous
email, where I took responsibility for updating the docs to 3.0.

> 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

Yes.

> development would be on making sure that all of the functionality from 2.x
> work in 3.x?

The major items not working are cut_regions, boolean regions, and
clump finding.  Anything else has either not been used and reported to
be failing, or is working.  The testing suite passes and in fact is
more extensive than the 2.X testing suite.

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

I think my goals are number one, to get anyone on this mailing list
who has not already tried to use 3.0 to try to use it, and number two,
to then attempt to migrate the broader community -- which I hope will
eventually bring with it a growth in the community.

The infrastructure of 3.0 has been shaken out considerably.  The
corner cases, the unforeseen bugs, all of that are the things that
need to be examined and worked with, and I can only identify so many
possibilities.  As I noted, there are extensive unit tests and answer
tests, but this will not catch everything.

Following that, making the backwards incompatible changes (noted
above) will be possible, and then we can attempt to shift development.

-Matt


> 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
>
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>