[yt-dev] Branches post 3.0

John ZuHone jzuhone at gmail.com
Wed Jul 23 08:13:55 PDT 2014


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20140723/5adefd8c/attachment.htm>


More information about the yt-dev mailing list