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

[Michael M Slusarz]

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.

michael

___________________________________
Michael Slusarz [slusarz at horde.org]