[yt-dev] Branches post 3.0

Cameron Hummels chummels at gmail.com
Wed Jul 23 09:34:37 PDT 2014


I like 2.x -> legacy, 3.0 -> stable, 3.x (dev) -> dev.

People are going to go to "stable" by default, and if we don't have a
"stable", I think they'll be a bit confused and not know whether to go with
legacy or modern.


On Wed, Jul 23, 2014 at 8:28 AM, Chris Malone <chris.m.malone at gmail.com>
wrote:

> 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
>>
>>
>
> _______________________________________________
> 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/20140723/7149e65b/attachment.htm>


More information about the yt-dev mailing list