There is a new version of the Horde framework and the other packages
that go with it. The new framework is 3.2.x and most of the other
<name>-h3-<version> apps also go up a minor number.


The problem with this upgrade is that there is a new database schema and
it is a "lots of admin action required" upgrade to a new version. I
can't really run the database upgrade SQL script during the upgrade
process, so the user is left with a broken system after the upgrade.


With enterprise linux distros, upgrades like this are to be avoided. So
the question is ... do we just leave Horde at latest 3.1.x level and use
3.2.X in CentOS-6?


There is the possibility of a horde32 (and all the others apps also as
required) and set that to conflict with "horde < 3.2" on C5, BUT that
introduces it's own issues.


My feeling is that we stick with the latest horde in the 3.1.x series in
CentOS-4 and CentOS-5 (which is 3.1.8) and we wait until CentOS-6 where
we will introduce the 3.2.x series (and all the associated apps).


What does everyone else think?

Thanks,
Johnny Hughes

_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel

Johnny Hughes a écrit :
There is a new version of the Horde framework and the other packages
that go with it. The new framework is 3.2.x and most of the other
<name>-h3-<version> apps also go up a minor number.


The problem with this upgrade is that there is a new database schema
and it is a "lots of admin action required" upgrade to a new version.
I can't really run the database upgrade SQL script during the upgrade
process, so the user is left with a broken system after the upgrade.


With enterprise linux distros, upgrades like this are to be avoided.


Yes that's really pityfull for end administrators.

So the question is ... do we just leave Horde at latest 3.1.x level
and use 3.2.X in CentOS-6?


There is the possibility of a horde32 (and all the others apps also as
required) and set that to conflict with "horde < 3.2" on C5, BUT that
introduces it's own issues.


My feeling is that we stick with the latest horde in the 3.1.x series
in CentOS-4 and CentOS-5 (which is 3.1.8) and we wait until CentOS-6
where we will introduce the 3.2.x series (and all the associated apps).


I you want to follow this way, provide Horde Webmail Groupware Edition
1.1.1, which is one bundle of all associed apps, seems better for me.



What does everyone else think?

Thanks,
Johnny Hughes

_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel

Jean-Marc LIGER wrote:

Johnny Hughes a écrit :


<snip>

My feeling is that we stick with the latest horde in the 3.1.x series
in CentOS-4 and CentOS-5 (which is 3.1.8) and we wait until CentOS-6
where we will introduce the 3.2.x series (and all the associated apps).


I you want to follow this way, provide Horde Webmail Groupware Edition
1.1.1, which is one bundle of all associed apps, seems better for me.




Right, the latest groupware version in CentOS-6 is also an option ...
although it is just all the components in one install. It still might
be easier to have them broken out. But, the either way, the result is
no upgrade that breaks horde now and an upgrade in CentOS-6.


_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel

On Tue, Jul 15, 2008 at 6:58 AM, Johnny Hughes <johnny@centos.org> wrote:

> Right, the latest groupware version in CentOS-6 is also an option ...
> although it is just all the components in one install. It still might be
> easier to have them broken out. But, the either way, the result is no
> upgrade that breaks horde now and an upgrade in CentOS-6.


What about an alternate install location, giving users a /horde/ and a
/horde32/ location or something similar.

This gives them the option to migrate at their leisure, and lets them
do the database operations on their own schedule. We can maintain both
in the repository at least temporarily.



--
During times of universal deceit, telling the truth becomes a revolutionary act.
George Orwell
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel

Dear Johnny.
*


The problem with this upgrade is that there is a new database schema and it is a "lots of admin action required" upgrade to a new version. *I can't really run the database upgrade SQL script during the upgrade process, so the user is left with a broken system after the upgrade.

Is this a problem with the database sheme or with RPM? Other Distributions like Debian use debconf (which I personally do not really like) to handle post-installation tasks like that.

Also RPM should be able to open a (gtk)dialog based script for configuration. It might also be an option to provide useful upgrade notices and a short link to them after package installation.


Best Regards
Marcus Moeller


_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel

Marcus Moeller wrote:
> Also RPM should be able to open a (gtk)dialog based script for
> configuration. It might also be an option to provide useful upgrade
> notices and a short link to them after package installation.

This is totally against (probably any) RPM-packaging guidelines. I
expect no CentOS developer would even consider this.

For other distros the solution is fine, as long as they are not RPM-based

Regards, Niels

_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel

2008/7/16 Niels de Vos <niels.devos@wincor-nixdorf.com>:

Marcus Moeller wrote:

> Also RPM should be able to open a (gtk)dialog based script for

> configuration. It might also be an option to provide useful upgrade

> notices and a short link to them after package installation.



This is totally against (probably any) RPM-packaging guidelines. I

expect no CentOS developer would even consider this.



For other distros the solution is fine, as long as they are not RPM-based
That's what I thought, too. But there is nothing wrong with good upgrade guidelines or different install locations, I guess.


Best Regards
Marcus

_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel

Marcus Moeller wrote:
>
>
> 2008/7/16 Niels de Vos <niels.devos@wincor-nixdorf.com
> <mailto:niels.devos@wincor-nixdorf.com>>:
>
> Marcus Moeller wrote:
> > Also RPM should be able to open a (gtk)dialog based script for
> > configuration. It might also be an option to provide useful upgrade
> > notices and a short link to them after package installation.
>
> This is totally against (probably any) RPM-packaging guidelines. I
> expect no CentOS developer would even consider this.
>
> For other distros the solution is fine, as long as they are not
> RPM-based
>
>
> That's what I thought, too. But there is nothing wrong with good upgrade
> guidelines or different install locations, I guess.

No, thats what I think too. Repackaging into hord32-RPMs is probably
most sane to do. Those who want to use the newer version will just need
to install hord32-... instead of hord-... This way even configuration
files and databases could be kept separately. For upgraders (manually?)
<http://www.horde.org/horde/docs/?f=UPGRADING.html> might be a good reading.

Thats just my €0,02.
Niels

_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel