I think everyone wants to know. But the answer is "when it's ready".
Fuel is a community framework, everyone working on it does so it his free time. Since that is variable, so is the timing.
The core team is going to meet up next week to see if we can compile the final todo list, including the high-level steps and/or design for those things on the list.
That should give us a better view on what still has to be done, and will allow the community to chip in.
We're also going to define the new docs system next week, so after that documentation can be written for the parts that are already finished.
Are there any features you're waiting for, or are you just curious?
"I read 2.0 - An update Written by : Harro Verton (WanWizard) ( Friday 23rd of August 2013 )"
I noticed one peculiarity in the plans for development FuelPHP
" The framework itself has been split into several packages, all Composer installable, and most of them are designed to be independent framework."
I think this is a big mistake, it's hard meaningless work will last for years and confusing for the practical application of zero. Here is a simple example , a nice package Monga , but not its integration with FuelPHP, but it is declared to be independent, why? Who is going to use outside FuelPHP? I remember ZendFramework 1.x was trying to do and came to a complete closure of the project. Now FuelPHP simple and clear, and will be as ZendFramework 2.x monster, why move to more complicated.
I love Fuelphp I use it in conjunction with Monga MongoDB . not enough of course their integratsii but this I do for himself.
If you want to use the package in a non-Fuel PHP application, go ahead. Currently, Monga is a very popular composer package for a Mongo abstraction layer (see https://packagist.org/packages/monga/monga for only the composer installs), and none of these users use Fuel v2 (because it isn't there yet). And why restrict that?
Note that this is not a design requirement. We will not weaken the design of the package to force it to be able to be used independently. The Framework always comes first.
But since one of the main architecture decisions for Fuel v2 is "no thight integration between classes" and "no static classes" because if makes unit testing impossible, all dependencies are injected and controlled by the dependency container. So even if the package has dependencies, it is up to you as a developer what you want to inject, if you decide to use the package stand-alone. Within the framework, this injection is done automatically, and is transparent for the developer.
What "framework integration" do you see for Monga, that you fear you are going to miss because "it can also be used outside Fuel"?
"If you want to use the package in a non-Fuel PHP application," on the contrary , I want to use FuelPHP whole I use Monga without fear, but as I have seen examples of such use, zero. But I am glad that there is such a service as part FuelPHP , but rather the integration of doing myself.
> But since one of the main architecture decisions for Fuel v2 is "no thight integration between classes" and "no static classes" because if makes unit testing impossible
I don't disagree with v2 architecture. But we could mock all static method with AspectMock, so we could test 100% even if it is v1 application.
Also, the static interface will make it very complicated to swap classes, which works a lot better with non-statics and a DiC.
Having said that, Fuel v2 will still have a static interface, but it will not contain any logic, it will just map to the default instance, like some classes in v1 already do (but in v1 they map to themselfs).
I didn't want to add a new thread. So - many thanks for this framework. I was using 1.7.1 in few latest projects and it works like a charm. How about 2.0 version? I've seen some updates on github, but there are no clear informations about 2.0 development status. And the website is not updated either. Can I contribute somehow? I could help with documentation etc. Greeting and again many thanks to FuelPHP developers.
Fuel is a community driven framework, which means it's direction can be controlled by the community, but it also means contributions all come from the community, and depend on free time available.
Most other frameworks out there are backed by a company, and have paid developers working on it. The plus of that is development has a more predicable pace, the minus is that the company might be a big influence and a single point of failure (see what happened to CodeIgniter since Ellislab stopped supporting it).
Things have been going rather slow over the last few months, due to personal circumstances of the core developers. The situation has been improved a bit, so you will see the pace going up from now.
This week a new core architecture emerged, work on Migrations and ORM started, Fieldset and Validation are close to being finished. So things abslutely happen! I'll try to find time this weekend to write a blog post on the new architecture (dubbed "Everthing is a Component").
One of the things lacking at the moment is a clear todo list, and a new documentation system. We need to get that up and running asap, since lack of that is currently blocking contributions from the community.
Once we've got a clear todo list, it will be easier to plan and get others involved. That also means there will be news for the website.
Oh, and while this is all happening, v1.x is also very much alive, and needs time spend on it. Time that will not be spend on developing v2, but as continuity is most important for us, stability of the current version goes above anything else.