[yt-dev] Branches post 3.0

[Douglas Harvey Rudd]

I was trying to come up with a similar name for an "old stable" and legacy is better than anything I came up with.  I think you should keep the name stable for the current version, however.

Douglas Rudd
Scientific Computing Consultant
Research Computing Center
drudd at uchicago.edu

On Jul 23, 2014, at 10:24 AM, Matthew Turk <matthewturk at gmail.com> wrote:

> This is a compelling argument.
> 
> What if we had:
> 
> stable => which we could call call "legacy" on the front page
> yt => which is mainline yt-3.0, called "modern" on the front page?
> 
> On Wed, Jul 23, 2014 at 10: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
>> 
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org