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

[Michael Rubinsky]

Quoting Michael M Slusarz <slusarz at horde.org>:

> Quoting Chuck Hagenbuch <chuck at horde.org>:
>
>> Quoting Michael M Slusarz <slusarz at horde.org>:
>>
>>> I will say I disagree with the speed of the release (me  
>>> complaining about release speeds?  The world has gone crazy).   
>>> We've been working on the H4 for essentially 4-5 years now.  We've  
>>> had betas/release candidates out for about a month.  With this  
>>> increased usage of these release candidates due to the testing  
>>> releases, the amount of bug reports/fixes has exploded.  The  
>>> increased eyeballs/usage is invaluable.  I don't feel like these  
>>> reports have tapered off over the course of the release cycle  
>>> (yet).  It seems to me that we stability of a release is more  
>>> important than a firm date.
>>
>> I guess I'd ask if you're worried about things that would  
>> potentially require backwards-incompatible changes right off the  
>> bat? If not, then I definitely vote for pushing ahead - if the .0  
>> is a little buggy, well, everyone expects that and we can improve  
>> it quickly.
>
> Gunnar pointed out flaws in the Mime_Part code that will only be  
> fixable with BC-incompatible changes (I think).  The good news is  
> that it doesn't affect anything we currently use Mime_Part for.  So  
> this could probably wait until 4.1 (or however we are going to do  
> this).
>
> But other things like the behavior of prefs_init.  There's a bug  
> open (#9728) where a user is trying to using application methods to  
> set prefs values.  But prefs_init is called BEFORE an application is  
> ever initialized (for obvious reasons) so any application method  
> that relies on things like session variables will not work properly.  
>  Not sure if this is a documentation issue, a design issue (although  
> I am 99% sure this is the way prefs hooks worked in H3 - not sure  
> how they could work otherwise), or something else.

FWIW, what this person is trying to do did not work in Horde 3 either.  
I'm not sure off hand what would need to call an Application method  
(not in front of code at the moment), but the share system must be  
available and useable in order for this to work since the source key  
("localsql" in this case) for the source's entry into $cfgSources[] is  
replaced by share identifiers during init. I can look into this  
further, but unfortuanatly probably not until Tuesday afternoon.

mike