[yt-dev] Branches post 3.0

[Chris Malone]

My main impetus for going with option 1 was so that there was a longer
delay for folks using 2.x.  I would be completely onboard with making 3.0
the 'modern' version, as long as users still have access to a 2.x for
awhile.


On Wed, Jul 23, 2014 at 9:24 AM, Michael Zingale <
michael.zingale at stonybrook.edu> wrote:

> I think I agree with John.  When people say "yt", we want that to be
> synonymous with 3.0 -- that's where the action is happening.
>
>
> On Wed, Jul 23, 2014 at 11:13 AM, John ZuHone <jzuhone at gmail.com> wrote:
>
>> I think that continuing to denote 2.x as "stable" leaves us in a
>> situation akin to Python 2.x vs. 3.x (though not quite as extreme of
>> course). I think that doing so will have a large effect on perception of
>> what people feel is "safe" to use for their analysis. We do think that 3.0
>> is indeed "safe" for this, right? If not, then we ought to state explicitly
>> that 3.0 is still in "beta" or at the very least is a "release candidate".
>> I don't think any of us would say that 3.0 is "beta" anymore.
>>
>> I'm just worried that it will slow migration to 3.0, at a time when most
>> of us have already switched over to thinking in terms of 3.0's syntax and
>> API. We'll certainly continue to support 2.x users, but I thought we wanted
>> them all to migrate (unless they need something that isn't ported yet).
>> Plus, it will certainly be confusing if we mark 2.x as "stable" but
>> nevertheless have all defaults (documentation links, etc.) point to 3.0.
>>
>> There are certainly a lot of things about 3.0 that are still maybe close
>> to the bleeding edge, but we've all done a lot of hard work in making sure
>> that the test suite still passes, which is more than you can say for a lot
>> of codes out there (though this situation is improving, thankfully). So 3.0
>> is pretty "stable", if you ask me.
>>
>> My last experience with something like this was the release of FLASH 3.0,
>> which was a pretty substantial break from previous versions. In that case,
>> we made no hesitations that 3.0 was the new "stable" version and strongly
>> encouraged folks to migrate from 2.x.
>>
>> So +1 on option 2, or something like it, with a 2.x branch remaining for
>> bugfixes.
>>
>> Sorry, didn't intend to write a book.
>>
>> On Jul 23, 2014, at 10:58 AM, Chris Malone <chris.m.malone at gmail.com>
>> wrote:
>>
>> +1 for option 1, but stress on the homepage all the cool things 3.0 can
>> bring to the table so that users are willing to break their scripts when
>> moving to the new API.
>>
>>
>> On Wed, Jul 23, 2014 at 5:18 AM, Matthew Turk <matthewturk at gmail.com>
>> wrote:
>>
>>> Hi everyone,
>>>
>>> Yesterday during the doc sprint, the question of what to do about
>>> branches post-3.0 came up.  Currently there are three branches, which
>>> correspond to different names on the front page of the yt homepage.
>>>
>>>  * Stable => The branch into which bug fixes are merged, but not a lot
>>> of active development occurs.
>>>  * yt => The 2.x development branch, which has slowed almost to a halt
>>>  * yt-3.0 => The 3.0 development branch
>>>
>>> It seems there is broad consensus that after the release, the yt-3.0
>>> branch would be merged into the yt branch.  (I would like to hold off
>>> on "closing" the yt-3.0 branch for a while, however.)  But, what is
>>> then to be done about the "stable" branch?  My thought was:
>>>
>>>  * stable => will be on 2.x for at least one release, until 3.1
>>>  * yt => 3.0
>>>  * yt-3.0 => we try to migrate development onto the yt branch, which
>>> is 3.0, but don't force yet
>>>
>>> The alternate idea was:
>>>
>>>  * stable => 3.0
>>>  * yt => 3.0
>>>  * yt-3.0 => closed
>>>
>>> I think we need a longer migration time for 2.x, though.  I will
>>> update YTEP-0008 with whatever we come up with, but is there a strong
>>> opinion for either of these options?  Option 1: stable stays 2.x for
>>> now, Option 2, stable becomes 3.0.
>>>
>>> -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
>>
>>
>>
>> _______________________________________________
>> yt-dev mailing list
>> yt-dev at lists.spacepope.org
>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>
>>
>
>
> --
> Michael Zingale
> Associate Professor
>
> Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, NY
> 11794-3800
> *phone*:  631-632-8225
> *e-mail*: Michael.Zingale at stonybrook.edu
> *web*: http://www.astro.sunysb.edu/mzingale
>
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20140723/d4443db7/attachment.html>