1.x to 2.0 Roadmap proposal

Major goals and

Tags: Plan
Roadmap

Trustmaster	#1 2011-10-05 06:01
Administrators Bedankt: 263 tijden	Now that Siena is just a few releases from stable state (1.0.0) and we have picked some fancy names for branches, I want to propose roadmap changes for further development. First, about 1.0.0 release. I've started a poll about branch name but now I think it is better to continue using the name of Siena for 1.0.x because 0.9.x will become 1.0.x without any major changes. This will indicate that 1.0.0 is Siena and users/coders don't need to change anything. Then, we can use Avila, Modena and Valencia to name our following major branches, such as 1.1, 1.2, 1.5 or 2.0. All branches in 1.x series are backwards compatible at plugin level, they bring new major features but in general old plugins will continue working. Each branch will have one main goal and several supplementary goals (features). Here the main goals I can see so far: Avila (1.1) - integrate ActiveRecord ORM and define Models for all basic modules. Modena (1.2) - implement View classes generating output for default Add/Edit/View/List operations. Valencia (1.5 or 2.0) - refactor module controllers to support automated unit testing and implement RESTful APIs for mobile development and web services. Some important goals which are assigned to current branch when it is time to: Centralized extension repository and online update of the core and extensions. Bridges to popular bulletin boards and image galleries. Please post your ideas below. May the Source be with you!

Trustmaster

#1 2011-10-05 06:01

Now that Siena is just a few releases from stable state (1.0.0) and we have picked some fancy names for branches, I want to propose roadmap changes for further development.

First, about 1.0.0 release. I've started a poll about branch name but now I think it is better to continue using the name of Siena for 1.0.x because 0.9.x will become 1.0.x without any major changes. This will indicate that 1.0.0 is Siena and users/coders don't need to change anything.

Then, we can use Avila, Modena and Valencia to name our following major branches, such as 1.1, 1.2, 1.5 or 2.0. All branches in 1.x series are backwards compatible at plugin level, they bring new major features but in general old plugins will continue working.

Each branch will have one main goal and several supplementary goals (features). Here the main goals I can see so far:

Avila (1.1) - integrate ActiveRecord ORM and define Models for all basic modules.
Modena (1.2) - implement View classes generating output for default Add/Edit/View/List operations.
Valencia (1.5 or 2.0) - refactor module controllers to support automated unit testing and implement RESTful APIs for mobile development and web services.

Some important goals which are assigned to current branch when it is time to:

Centralized extension repository and online update of the core and extensions.
Bridges to popular bulletin boards and image galleries.

Please post your ideas below.

May the Source be with you!

GHengeveld	#2 2011-10-05 21:30
Team Bedankt: 52 tijden	Along with the integration of an ORM I suggest we strive to write modules in Object-Oriented fashion. Plugins can remain procedural style. In order to write true (nice) OO code, I'd like to refrain from using globals ($db, $L) in class methods. This means we'll need another way of accessing them within a class. In case of $db this is best done by deriving (extending) model classes from the CotDB class. Added bonus: database queries can only be executed from the model, keeping true to MVC pattern. For $L I think we'll need a static method, for example: $L['name'] becomes L::string('name'). This also allows for more flexibility by using other methods, for example L::format('name', array('a', 'b')). View classes could extend CoTemplate class, but I'm not sure we should because a View isn't neccesarily parsed by CoTemplate, it could also be JSON, XML or some other weird format (even a binary file). In my opinion RESTful principles should be the basis of every module and alternate output formats such as JSON or XML should be supported by default. This will make the link to mobile/webservices much easier.

GHengeveld

#2 2011-10-05 21:30

Team
Bedankt: 52 tijden

Along with the integration of an ORM I suggest we strive to write modules in Object-Oriented fashion. Plugins can remain procedural style. In order to write true (nice) OO code, I'd like to refrain from using globals ($db, $L) in class methods. This means we'll need another way of accessing them within a class. In case of $db this is best done by deriving (extending) model classes from the CotDB class. Added bonus: database queries can only be executed from the model, keeping true to MVC pattern.

For $L I think we'll need a static method, for example: $L['name'] becomes L::string('name'). This also allows for more flexibility by using other methods, for example L::format('name', array('a', 'b')).

View classes could extend CoTemplate class, but I'm not sure we should because a View isn't neccesarily parsed by CoTemplate, it could also be JSON, XML or some other weird format (even a binary file).

In my opinion RESTful principles should be the basis of every module and alternate output formats such as JSON or XML should be supported by default. This will make the link to mobile/webservices much easier.