Inspired by Bruce Morrison's post in his blog: http://suffandnonsense.blogspot.com/2008/02/is...
I kind of understand the disappointment with minor revolution of the current big version 4.0, although I had known (more or less) what to expect when I was awaiting it few months back. You can ask yourself: was PHP5 more of an improvement, or maybe a necessity? If the latter, the smaller was the step ahead, indeed. Nevertheless, I am very glad this step was made, no matter what the version is called, for reasons that must be obvious. Back to the expectations, I can only imagine how 3.x introduction was different (greater) to 4.x, because I've only known eZ Publish since 3.8.x or so (BTW: have to admit I gave up after several attempts with 3.5... it beat me!).
Bruce's suggestion is to put eZ Publish 4.0 at its rather stable state into feature freeze mode, while concentrating efforts on taking full advantage of the maturing eZ Components to produce the next big version (5.0) from scratch. I have to say that I like this idea for similar reasons:
There's another thing, but it deserves to be covered in its own paragraph.
In my comparatively short experience with eZ Publish, I have already dug deep enough to see its few weaknesses, especially regarding the content and storage models. Don't get me wrong, by no means would I call eZ Publish weak, it's just that it has its limitations defined and there are only so many things you can do with it without hacking or severely extending.
Now, I do understand how big part various "rich" features play in the eZ business model and in those of many eZ partners. For example, extensions such as eZ Flow or Web interfaces that make it possible to have an advanced out-of-the-box product with time required for implementation significantly reduced. Having seen how business-oriented eZ people are, I do not expect this direction to be given up at any stage (and I like that).
However, I hope that that direction does not prevent from improving the application at its core, that is the foundation for all eZ business after all. Unlike presentation layer or even more advanced extensions, which can be developed independently, core upgrades would be rather difficult to be introduced by means of hacking the kernel. I'd like to be optimistic, but don't see alternative storage models or advanced class features coming any time soon. New rebuild could be an ideal opportunity to make eZ Publish even more versatile and fit to solve even more advanced content management tasks (and not only!).
It doesn't seem like this issue is up for a discussion, but I haven't heard anything official on eZ Publish 5.0, yet. So, maybe it is not too late ;)
If you ask me, I think I could live in this 4.0 feature freeze mode... if what I was waiting for was a completely new eZ Publish 5.0 in a year or two, with even greater core features and as few compromises as possible.
Introducing two new components: Tree and Webdav.
The Tree component enables to create, manipulate and query tree structures, with several back-ends available, each with different performance-related properties. Two tie-ins are available for this extension: TreeDatabaseTiein for storing tree structures in a database (which is recommended at this point) and TreePersistentObjectTiein.
The Webdav component brings easy setup if a WebDAV-enabled HTTP server, which results in users' ability to create and edit site content by uploading and downloading files to and from their desktop. The current implementation is compatible with RFC 2518. It also supports clients that do not conform to the standard and provides an interface to support these clients. This component does not have any other dependencies besides PHP (and the required extensions), nor does it require any Apache modules.
For both PHP 5.2.1 or higher is required.
This release also brings some changes, mainly to Cache, EventLog, Graph, and more.
Full details: http://ezcomponents.org/resources/news/news-2007-12-17
There's a completely non-invasive method of making eZ Components available for eZ Publish installation, which would be especially useful in shared hosting environment, where custom server changes are not allowed or possible. Simply place your eZ Components bundle wherever that eZ Publish'es PHP can reach. Then create a config.php file on the eZ installation's root, and set additional include paths for PHP:
$ezcSharedHostingPath = './ezc/';
ini_set( 'include_path', ini_get( 'include_path' ). ':'.$ezcSharedHostingPath );
Just adjust the path matching your environment, and that's it. eZ 4 already knows that it should look for it.