Share » Forums » Install & configuration » consider new release candidates...

consider new release candidates instead of 4.0.0 and 3.10.0

consider new release candidates instead of 4.0.0 and 3.10.0

Wednesday 02 July 2008 12:16:25 pm - 6 replies

Author Message

Hans Melis

Wednesday 02 July 2008 2:07:13 pm

I don't know if it's safe to assume they are more stable, not just because they are RC but because they contain some complex fixes.

The URL alias system introduced in 3.10 and the multilingual features in 3.9+ (or was it .8?) use bit logic. The major bugs in those two systems are caused by incorrect bit logic and the code is very complex. Those two factors also contribute to the complexity of fixing those bugs. I'm sure eZ staff has done all they can to ensure the fixes are correct, but given their complexity it was a wise decision to go to RC stage first. The RCs are really meant to be used on test installs, not on production sites.

New installs with the RC are less of a problem than upgrades. When upgrading to e.g. 4.0.1rc1 all custom URL aliases will be gone. This might also be the case for the final release, but at least they're not excluding the possibility of an upgrade script. That very issue is critical for one of our production sites which means it can't be upgraded to 4.0.1rc1. Instead I have installed a separate copy of the site on the development server and copied the RC sources over it.

Another issue that could matter is support. RCs are unstable releases so it's quite likely you can't get support for them. I don't know eZ's policy on that matter, but it wouldn't surprise me.

Yes, the 3.10.0 and 4.0.0 have a lot of issues that have been fixed by now, but none of them block the use of those releases in production sites. The URL alias system occasionally throws a fit, but nothing I can't recover manually. And so far, each hickup only prevented editing the site, never the reading part. And a monolingual site is absolutely safe.


Bruce Morrison

Wednesday 02 July 2008 4:27:01 pm


A RC is a release candidate and eZ put it out there for people to test and evaluate. It's not final so things may change. Personally I wouldn't use RC releases for anything else but evaluation.

And a monolingual site is absolutely safe.

I'm not 100% sure that this is the case. It's my understanding that the severity of the issue in monolingual sites is lessened there is still the potential for the url_alias history to be corrupted.


My Blog:
Follow me on twitter:
Consolidated eZ Publish Feed :

Daniel Arnrup-Øien

Monday 07 July 2008 2:54:17 am

We are running 4.0.1rc1 on our production sites (of which 2 are multilingual) and the release has been running smoothly on our server since June 29.

Note that we are handling URL alias translation through mod_rewrite until the URL alias system is fully fixed. I have also temporarily implemented Tobias Vogel's fetch_url_alias extension to fix our language switcher. Thanks Tobias!

We intended to upgrade to 4.0 and decided to go for 4.0.1rc1 after reviewing the bug fix list. So far it seems to be a good choice.

Daniel A. Øien
Open Concept SA, Norway
In English:

zurgutt -

Tuesday 08 July 2008 5:35:33 am

What really prompted me to write this post is not primarily bugginess of the current official versions but the lamentable custom of eZ systems to not share beta versions or information about them with general public.

In my opinion this goes against open source best practices and customs and is a disservice to everyone using eZ Publish. The whole point of betas and release candidates is to get as many people as possible to use and test them, to find and fix bugs. Many eyeballs makes bugs shallow, remember?

The natural place to inform people about betas would be the download page. Virtually any opensource software i know lists latest betas on download page and encourages people to try them out - with due warning about their betaness of course. I believe not having the betas publicly out will eventually backfire on everyone, including the paying customers of eZ Systems and eZ Systems itself. In fact I believe this is already happening.

To refute the possible point about betas not being "supported" - this is totally moot. Of course they are not supported. That is ok - vast majority of eZ Publish users dont buy commercial support from eZ Systems and never will. Those who do are smart enough to pick a supported version suggested to them.

I hereby respectfully invite eZ Systems to change their policy and start openly providing beta versions and patches for critical bugs in official versions on the download page, for the benefit of whole community. If you agree with me, please post here. I believe eZ Systems cares about the community and will come to meet our wishes :)

Certified eZ developer looking for projects.
zurgutt at

Thomas Koch

Tuesday 08 July 2008 6:23:20 am

Hi Zurgutt,

while I have other issues with communication style of eZ Systems (any official information about the new roadmap presented on the conference?), I think that this one is no issue.

eZPublish is not like many other software projects. It is no peace of software, that somebody installs in a day, but it's a base for specialised partners to build long time projects on it.

I think that every partner had the opportunity to track the availability of the RCs either on planetezpublish or via SVN. The RCs are of no interest for the general public.

But you still hit a point: Why hasn't there been an announcement on

Thomas Koch |
YMC - eZ Publish in Switzerland |

Linh Vu

Wednesday 09 July 2008 10:26:38 pm

3.10.1 RC has been solid for 4 ezpublish sites that I've upgraded from 3.9 to.

I hope eZ System will get a stable 4.0.x out soon though. It's now very close to PHP4 EOL (08/08/08) and ezpublish is way behind other open source web PHP apps in the migration to PHP5. The current 4.0.0 (I haven't tried 4.0.1 RC) is very buggy.

If I had more time, I would write less code.

You must be logged in to post messages in this topic!

36 542 Users on board!

Forums menu