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