eZ Community » Forums » Install & configuration » Updating from 4.3.0 to 4.3.1 (from...
expandshrink

Updating from 4.3.0 to 4.3.1 (from git), some glitches

Updating from 4.3.0 to 4.3.1 (from git), some glitches

Tuesday 14 September 2010 2:45:52 pm - 2 replies

I pulled the latest version from stable-4.3 branch in order to update a 4.3.0 eZPublish and reviewing the changes made I encountered some things I want to mention here and requesting feedback from the community.
Info: I pulled today, because for a few days no patches were introduced in the stable-4.3 branch so i assume eZPublish 4.3.1 is out ... somehow ... blunk.gif Emoticon
.
.

First there are missing sql-statements for adding a few new keys to table "ezinfocollection_attribute" introduced in 4.3.1. The file "update/database/mysql/4.3/dbupdate-4.3.0-to-4.3.1.sql" misses the following statements:

ALTER TABLE ezinfocollection_attribute ADD KEY ezinfocollection_attr_cca_id (contentclass_attribute_id);
ALTER TABLE ezinfocollection_attribute ADD KEY ezinfocollection_attr_coa_id (contentobject_attribute_id);
ALTER TABLE ezinfocollection_attribute ADD KEY ezinfocollection_attr_ic_id (informationcollection_id);

See "kernel/sql/mysql/kernel_schema.sql" in the git-stable-4.3 version as reference, line 714 and following.

.
.

Second nearly every php-file has been changed when diff'ing to a plain downloaded 4.3.0 eZPublish from ez.no. The downloaded official Release has a disclaimer comment in each php-head stating the version as "@version 4.3.0". The (not all, thats weird) files from git stable-4.3 are stating "@version 4.1.x" or "@version //autogen//". It would be much more straight forward if upcoming new community-releases or non-official releases would state "@version 4.3.x" or "@version 4.4.x" in order to maintain a clean merge-process for only a few files that really introduced modifications that matter.

I see that has been done in git-master already. But stable-4.3 at the time is a pain to merge blunk.gif Emoticon

.
.

edit/update: Found something new. a Lot of ini-files in /settings/* were modified. Example:

TemporaryPermissions=0777##!
#!TemporaryPermissions=0777

How can I/we deal with that? What should be the best way to merge such stuff into an existing ez-installation which has official release quality? Why has such code been commited to git?

.
.

Thats it. Just awaiting feedback before slamming the issuetracker.
A note aside: Not publishing any bugfix-releases anymore seems not to be real technical issue as using basic git-commands enables you to get the latest fixes for your ez-version. Followed by a merge and you are done.

cheers,
chris

Modified on Tuesday 14 September 2010 3:17:09 pm by Christian Rößler

Tuesday 14 September 2010 4:01:32 pm

There is no 4.3.1 release scheduled at this time - the next release is eZ Publish 4.4, due in two weeks.

Various fixes are backported as part of normal development, but the git branch is not meant for direct consumption. Thus, if you run it, expect to run into problems. The best way to get an up to date installation, is to use 4.3.0 and the automated patch service that is part of eZ Publish premium

Tuesday 14 September 2010 4:59:18 pm

Yea, I know there are no maintenace releases anymore. This was point of discussion a few months/weeks ago here in the community. Ok, so dump the questions according to git and what is in there.

But there is still the issue with the missing sql-update statements eZSystems should know about. As I don't know if your "automated patch service" has or has not this sql-statement in it, I thought posting those things might be useful. Especially for your paying premium customers.

expandshrink

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

36 542 Users on board!

Forums menu

Proudly Developed with from