[dev] [commits] Horde branch master updated. aa8beb599eaa8ed0556da685f3e80357230bbb18

[Jan Schneider]

Zitat von Gunnar Wrobel <wrobel at horde.org>:

> Hi Jan,
>
> Quoting Jan Schneider <jan at horde.org>:
>
>> The branch "master" has been updated.
>> The following is a summary of the commits.
>>
>> from: a193d258e997d598fd4a406239b89b8e2ed4cca7
>>
>> aa8beb5 Require Horde_Perms 1.0.3 because the new code triggers a  
>> bug in older versions now.
>>
>> -----------------------------------------------------------------------
>>
>> commit aa8beb599eaa8ed0556da685f3e80357230bbb18
>> Author: Jan Schneider <jan at horde.org>
>> Date:   Fri Jul 29 17:43:55 2011 +0200
>>
>>    Require Horde_Perms 1.0.3 because the new code triggers a bug in  
>> older versions now.
>>
>> kronolith/package.xml |    2 +-
>> nag/package.xml       |    2 +-
>> 2 files changed, 2 insertions(+), 2 deletions(-)
>>
>> http://git.horde.org/horde-git/-/commit/aa8beb599eaa8ed0556da685f3e80357230bbb18
>>
>
> a while ago - I think when I modified Horde_Prefs to require  
> Kolab_Storage-1.1.0 - you mentioned that we avoid requiring higher  
> versions for reasons of backward compatility. This commit here  
> reminded me that I still wanted to pick up the discussion on this.
>
> I think it makes perfect sense to allow us to require higher  
> versions of dependencies to get access to newer features. And I  
> don't see a possiblilty where this could break since we rely on PEAR  
> to manage the dependencies for us.
>
> Does your commit indicate that you see it the same way?

Not quite. We discussed about this in http://bugs.horde.org/ticket/10093#c23

I could agree on making it a general rule to allow requiring more  
recent, backward compatible framework packages, if that is consensus.

There are already a few places where I actually use this:
- In the groupware releases, to make sure that people have certain  
minimum versions of Horde applications when they talk about a certain  
groupware version.
- To enforce upgrading of dependent components that had security releases.
- To enforce upgrading of dependent components that had fixes for bugs  
that are triggered with adding new functionality.

Since these are already a bunch exceptions from the rule, we should  
probably make these exceptions the rule instead.

It should be clear though (an this is what the discussion in the  
linked ticket is partially about), that it's not allowed to introduce  
bc breaking changes in a package and then simply requiring that newer  
version in further application releases.

And we should discuss whether we want this to be a "hard" dependency.  
I.e. whether we should still fail gracefully in the code if a new  
feature is not available. Though it probably doesn't make sense to add  
a higher dependency version at all then.

Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/