Make a Lasting Impression

Join the Mailing List

Who's Online

21 user(s) are online (3 user(s) are browsing ImpressCMS Blog)

Members: 1
Guests: 20

fiammybe, more...
ImpressCMS proudly uses SourceForge
ImpressCMS on Ohloh.net
ImpressCMS Blog > Scoping ImpressCMS 2.0

Scoping ImpressCMS 2.0

The pace of development in open source projects is not always easily predictable. Most work is done by people investing their free time into the project. By definition, that amount of free time is subject to all kinds of factors, which we call ‘Real Life’. Family, children, going out and meeting people, job worries, … they all can have an impact on the amount of time one is able to invest in a project.


Project Balance


In order to keep the interest in your project high, you need to find a good balance between quality, release interval and evolutions. That balance must be checked off periodically, to see if you can still reach your version goals with the number of contributors and their amount of effort they can invest.


For ImpressCMS 2.0, we’ve been working in a small team now for the last couple of months, and we have made progress, but at this pace, it will take us more than a year extra to finish the existing roadmap. That won’t do of course.


System module refactor


We’ve come to the conclusion that the refactor of the system module is a project that can be done over multiple releases. We can safely release a new version of ImpressCMS with a partial refactored system module, as long as everything works as it should, this shouldn’t hold us back.


Of course, most of the development until now had been focused on that system module refactor, so we will need to have some extra features that will make it easier for users to use the system. Breaking down the barriers, like we have been proclaiming for some time now.


Preference for 2.0 branch


To that end, we decided some time ago to limit the developments on the 1.3 branch to security fixes, and to some easily backported items from the upcoming 2.0 branch. We will also need to figure out which improvements we will tackle in the 2.0 release, and which parts to leave for later releases.


This choice will be heavily based on community participation.


The big zones for improvement in ImpressCMS 2.0 were:


  • Rework the PM system
  • Rework the comment system
  • Improve the Notification system
  • Theme Control Panel
  • Improve Installer
  • Enhance Module installation and management
  • Changes for PHP 5.4 compliance
  • Optimizing size

External Library upgrades These are all big blocks to tackle with our current contributors, so in order to make a faster release possible, some parts will have to be pushed back to a later release.


I welcome discussion on the forums on this, and of course having some extra contributors for one of these improvement zones will make it more likely that that particular change gets in the next release.

All posts by fiammybe
Subscribe to latest posts
The comments are owned by the poster. We aren't responsible for their content.
Poster Thread
Will
Posted: 2012/7/12 21:27  Updated: 2012/7/12 21:27
Home away from home
Joined: 2007/12/4
From: Dallas, TX
Posts: 3556
 Re: Scoping ImpressCMS 2.0
Theme CP and Installer are at the top of my list - I personally like the wordpress installer - and see no reason why ICMS couldn't have a similar installer. All the extra stuff we do during install seems unnecessary.
Madfish
Posted: 2012/7/13 3:57  Updated: 2012/7/13 3:58
Home away from home
Joined: 2007/12/4
From:
Posts: 1127
 Re: Scoping ImpressCMS 2.0
Just a random thought on comments - since they are basically organised into threads, would it be possible to design with a view to them being used as the building blocks of future forum modules?

Or to put it another way, if forum modules were able to use a core comment object as their foundation (rather than inventing their own class for posts or threads) then it might be easier to integrate forums seamlessly into a site. And also to build forum modules, or to migrate content between forums.

Re. notifications, I will just say in developing a new module this is the most difficult bit of the backend to wire up. If it could be simplified somehow, that would be great.

One other thing I am currently looking into - my impression is that the IPF tables might have some HTML validation issues that require some template alterations, but I need to dig into it deeper to be sure.