About Yii 1.1.x and future plan

Yii 1.1 General Discussion
1

Since its initial formal release in December 2008, Yii has been growing rapidly in both its user base and functionalities. Yii has been cited as one of the most favorable PHP frameworks in several places. Thank you all for your support!

Looking forward, we will continue to make Yii a high-quality, flexible and powerful framework. In this post, we summarize the release plan and roadmap ahead.

Version 1.0.5 marks the end of major feature enhancements in the 1.0 branch. All future 1.0.x releases will only contain bug fixes and very minor feature enhancements that keep strict backward compatibility. We will keep maintaining this branch till December 31, 2010.

Starting from May 11, 2009, we will use the trunk (1.1 branch) to develop major feature enhancements. We expect to make the 1.1 alpha release in October 2009.

For the upcoming 1.1 releases, we plan to accomplish the following major tasks:

  1. Unit and functionality test support for user applications. It will be based on PHPUnit and Selenium.

  2. An open architecture Web-based console for Web application development and management. It may be considered as a Web-based version of yiic (but much more powerful).

  3. Implement a set of official extensions that will be released as a separate package from the core framework.

If you have any suggestion for the above tasks or other feature enhancements, please use this thread or board to discuss it. Thank you very much!

2

Very good!  Happy to hear this.  I'm especially happy about the upcoming web-based-console, I think it will can do a lot.  I have a list of ideas I can jot down after finals in 2 weeks

3

Great news. Unit Testing is one of the few things that Yii is lacking on so it's great to see that it'll be coming soon!

4

Great news! The web-based yiic tool will be so much apreciated!

5

I'm happy to hear about the set of official extensions. Thanks for your great work! Yii Framework helped our team to easily create a fully-functional application!!

6

Perfect! This frameworks is amazing "as is". I can't imagine what will happen when we have in our hands the yii 3.0 (jejeje)… But I sure that this will be good… very good…

7

Good to see the roadmap. I've just one question about blog tutorial. Will it be extended before 1.1 will come? Do you have in plans to create any other, more complicated, example of usage Yii framework?

8

Great! A roadmap make me has confidence in develop my new project based on Yii.

9

Quote

Good to see the roadmap. I've just one question about blog tutorial. Will it be extended before 1.1 will come? Do you have in plans to create any other, more complicated, example of usage Yii framework?

We don't have plan to create a more complicated example for the 1.1 release. Instead, we will focus on enriching the cookbook with more small tutorials on using various parts of Yii.

10

Does this mean also that blog tutorial will not be changed? Does it me that we can start to translate it?

11

Yes! I just updated yiidoc so that we can start translating the blog tutorial.

12

thx, karma++ for quick update :)

13

This might have been taken into consideration already, but what I think that might be intresting is the support for database migrations. The idea I have in mind could be slightly based on the Akelos-framework (but then in the better structured YII way), that actually does the following:

The information needed to describe the database in a certain version should be PHP code. In the Akelos framework there is a special Installer-class with a couple of functions for each version, but it might be even better to just use a function in the model (like tablename) that just returns the (incremental) database setup. Then it would be fabulous if Yii automatically takes care of the database management.

For instance, a declaration in a model file could look like this:

        /**


         *


         * @return array all the table setups for different versions


         */


        public function tableSetup() {


            return array(


                '1' => // Version 1


                array(


                    'id'=>array('INTEGER','PK','AUTOINCREMENT'),


                    'name'=>array('VARCHAR(255)'),


                ),


                '2' => // Version 2; this code could be created later on


                array (


                    'id',       // Inherited from version 1


                    'name',     // Ditto; if we'd remove this line the field would be removed from the database as soon as we migrate to version 2


                    'createTime'=>array('INTEGER'),


                ),


            );


        }





        public function tableCurrentVersoin() {


            return '2'; // Sets the current version;


        }

Here are two versions (version 2 is created after version 1) and the tableCurrentVersion represents the version that is to be used. Since the fields are set up incrementally, usefull migrations can be calculated from and to any particular version.

Then you can choose to let the framework check the table setup automatically on each loading of the model, or (better, I think) you can make a 'migrate' command in the yiic tool if you prefer performance at application runtime. (Since migrations of course shouldn't take place in a production scene.)

This is useful if you are developing an application using a versoin control system, and if we want to have a working copy of not only the code, but also the database setup.

Also, it would be nice to have these functions above automatically generated if at the model-generation time the table already exists.

Let me hear whether this idea sounds interesting to you guys!

edit: corrected a few typos

14

@pelleke

there's no fine line between features that bloat a framework and those that don't, but perhaps that would be better as an extension/behavior (even a core behavior, but not part of the CActiveRecord class)

…in my opinion

15

excellent new for the Yii framework !! … keep up the good job ;)

8)

16

I love the idea of migration like Rails migration.

If you plan to implement migration, please don't use sequenced number for migration revisions (1,2,3…) because it's unusable with version control :

user1 generate locally a new migration with number = 3

user2 generate locally a new migration with number = 3

:frowning:

Rails generate a random number for migration revision and store all the migration revisions in the migration table.

17

Rails uses timestamps AFAIK and that works pretty well.

18

Yep, it's a timestamp !

19

Migrations is a real must to have ;)

20

You mentioned a set of official extensions. Could you please describe that further?

Have you thought of feed generation/aggregation, xmlrpc, smtp support and other weby components? I’m looking forward to hearing your thoughts on this.