[yt-dev] Branches post 3.0

[Matthew Turk]

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
>