Donate
At the beginning of 2012 Jelmer posted an article called "The road ahead", outlining the developments of what was back then referred to as "FuelPHP 2.0".
In the 10 months that has followed, a lot has changed. Two members have left the core development team, one of them being the projects founder, and the project has found new leadership. New leadership usually brings change, and for us, there is no exception.
This year, Jelmer has posted several articles outlining the new architecture and the reasoning behind it. He has worked very hard translating it into code, using the fulphp development repositories on github.
All this activity has lead to rumours and discussions about a new 2.0 version, and a possibility of an immiment release. I want to use this article to explain what we are doing, how we see the road ahead, and how we intend to arrive at the new architecture outlined by Jelmer.
Most software developers are always looking for the newest, latest and greatest. Nothing wrong with that, it's in their nature. However, when you run a project like FuelPHP, there are other things to consider. We have a lot of users, all having a vested interest in the framework. Amongst these users are large web development companies that have standardized on our framework for the development of sometimes very large business applications.
For those users, switching to a dramatically different architecture means basically switching to a new framework. It will have a huge impact on their business. What to do with applications that are currently in development? What to do with finished applications that are in a maintenance cycle? Most bussiness applications have to be operational and supported for 5 or more years, switching these to a new framework architecture will be a very expensive excercise. And leaving them on an old and no longer supported version of the framework is often not an option either.
To overcome these issues, we had to find a way to bridge the gap between the current release version and the proposed new architecture and bridge it in such a way that the impact for our users is minimal. At the same time, we have to make sure that we stay focused on the end goal, and get there in a timely fashion.
So we have decided not to go for a big bang approach. Instead, now that version 1.4 is released we're going to make changes in the next couple of version 1 releases that will bring it closer to the new architecture, so that the eventual switch to version 2 isn't such a big hurde to take.
In the next couple of releases, we're going to:
Check out our roadmap for a complete list of defined activities, the status of these activities, for which release they are planned, and who is working on it.
It is our intention to make this changes with as little impact as possible, to keep the migration effort between releases to a minumum.