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

[Gunnar Wrobel]

Quoting Jan Schneider <jan at horde.org>:

> 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.

 From my side I'm 100% certain that I want this because this gives us  
a lot more flexibility with new features that we won't have otherwise.

>
> 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.

Great! ;)

>
> 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.

That is obvious and I won't disagree on that. Upgrading a framework  
package (within the version range specified for one Horde major  
version - "4" now and "1.0.0" - "2.0.0 [excluded]") may *never* lead  
to failure of a dependant package. Otherwise the dependencies we  
specify make no sense.

>
> 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.

Yes.

Cheers,

Gunnar

>
> Jan.
>
> -- 
> Do you need professional PHP or Horde consulting?
> http://horde.org/consulting/
>
> -- 
> Horde developers mailing list
> Frequently Asked Questions: http://horde.org/faq/
> To unsubscribe, mail: dev-unsubscribe at lists.horde.org

-- 
Core Developer
The Horde Project

e: wrobel at horde.org
t: +49 700 6245 0000
w: http://www.horde.org

pgp: 9703 43BE
tweets: http://twitter.com/pardus_de
blog: http://log.pardus.de