All I can tell you at the moment is that the goal is that we're going to make that as easy as possible. We all have existing applications too, and we hate migrations effort as much as you do.
As 2.0 isn't finished yet, we haven't made the 1.x compatibility package yet (which we can't until 2.0 is sufficiently finished), and we haven't done any upgrades ourselfs, there isn't anything more to say at the moment.
A compatibility package is great but I still wonder what it takes to actually migrate from FuelPHP ~1 to 2. There's a big project coming up where we'd like to start working sometime in spring 2014. We're still not sure what framework to use...
FuelPHP is one but the upcoming version makes things a bit difficult. If we start in spring, we wouldn't want to start with 1.7 and even if there's a compatibility package, having proper 2.0 code is a must for us.
If it's just about snake- and camelcase stuff, okay.. A bit boring but we can easily change these things. But what about the classes itself, will the routing, ORM system look vastly different?
I understand your problem, but it's too early to tell.
All I can say is that for us, FuelPHP is a means of making money, and not a hobby project, or a "pet project" from some commercial company like many other frameworks out there.
This means that a major rewrite of existing applications (my company specializes in corporate applications, which usually have a 3-5 year life cycle) is an expensive and time consuming exercise, which whe want to avoid at all costs. In that respect we're in the same boat.
For the part of v2 that is finished, the API isn't that different, and for the few methods that are, it's easy to create an alias in some compatibility package, that will log it's use, aiding in removing those from existing code.
Some stuff, like Auth and Orm, are going to be different, which is inevitable since we need to solve some architectural issues in the current design. But it would not be very complicated to make the existing v1 packages available as-is in v2, solving the compatibility issue for those.
Besides all this, once v2 will be ready for release, we will release an LTS version of v1. So if you have an existing application, and you have no functional need to upgrade to v2, you are safe in the knowledge that your application runs on a supported platform.
And for most existing applications, there is probably no need to upgrade. From a functional point of view, you would want to upgrade if you have a need for: - event driven applications - multiple application support - hybrid (direct and HMVC) controller action support - support for an RDBMS different from MySQL - object oriented form generation and validation
The other way is also true, since v2 will be constructed from composer packages, you can choose to select new bits of functionality (like for example the database package, or the new fieldset/validation package) and include them in a v1 application. We already do.
Other then that, most of the work in v2 is under the hood, and related to removing the static API from the code to make the framework code testable, splitting the framework in packages for easier maintenance and upgrades, etc.
Donate
