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@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@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@lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________
yt-dev mailing list
yt-dev@lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org