[dev] Horde release cycle

[Gunnar Wrobel]

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

> Quoting Chuck Hagenbuch <chuck at horde.org>:
>
>> Quoting Ralf Lang <lang at b1-systems.de>:
>>
>>>> I've tried to synthesize this thread into a concrete proposal here:
>>>> http://wiki.horde.org/Draft+Release+Cycle
>>>>
>>>> I don't claim that I've taken everyone's feedback into account because
>>>> some viewpoints were opposing. :) But I did try to go with consensus
>>>> where it seemed to exist.
>>>
>>> The page content seems like the direction that would work for me.
>>>
>>> Question:
>>>
>>> In the page you say you expect major releases about 12-18 months  
>>> and you want
>>> to support the current and previous release.
>>>
>>> This would mean with H4 coming in april 2011, H3 will not see end of life
>>> before april 2012, right?
>>
>> Yup, that's what we'd be committing to if we adopted that policy.
>
> Coming in VERY late to this conversation, but wanted to add just a  
> bit of input based on things/code I maintain (e.g. IMP)...
>
> I am *very* concerned about BC issues.  BC issues essentially  
> stalled development on IMP 4 for the last 3-4 years.  Some of this  
> has to do with the fact that a bunch of IMP was abstracted out and  
> moved to the framework Horde in the interests of reusable code.  I  
> can now say, in hindsight, that this was one of the worst design  
> decisions I ever made.  The MIME code was not stable enough for this  
> to happen when it did, our rendering code was tied up in  
> framework/Horde, and it became near impossible to make UI changes to  
> incorporate new features that were not expected before.
>
> Truthfully, the moral of the story is/was that I should have  
> self-contained all the necessary code in IMP to prevent these  
> issues.  This sort of destroys the whole idea of using a framework,  
> but from an application level it works much better.

Argh, I have to go off on a short rant even though I assume you  
exaggerated a bit here to make your point...

Man, do you know that you write good code? You really, really want to  
have Horde_Imap_Client and Horde_Mime within Imp?

No way, not a chance!

You know quite well that there is no decent standalone IMAP client  
library in the PHP world out there. You even know that your  
Imap_Client is faster than the cclient crap (coded in C!) that stock  
PHP offers. And you want to keep it for yourself within Imp?

No way, not a chance!

I could tell you quite a story about the use of IMAP libraries in  
larger PHP projects. Things like people using the "Mail" component  
from Zeta components for IMAP access. Just because there is not much  
else out there. Hello?

Imap_Client is great and it is going to be a stand-alone Horde  
component. Period! ;)

Cheers,

Gunnar

>
> I bring this up because, quite frankly, I am a bit concerned about  
> BC issues with the forthcoming release.  For IMP we have brand new  
> IMAP, MIME, and rendering libraries (again).  I'd like to think  
> these libraries are much better and more stable than their  
> predecessors.  But bugs and design flaws have a way of not rearing  
> their ugly head until after the first stable version is released.   
> (e.g. I am currently in the process of rewriting a bunch of IMAP  
> fetch code because in order to better handle broken input from IMAP  
> servers.)
>
> It sounds like there is a plan to churn releases out on a regular  
> basis.  This is a good thing.  But I am against the idea that,  
> within a given major release for example, we are allowed absolutely  
> NO BC changes.  If something is irreparably broken, it needs to be  
> fixed.  If some design decision we made in the last few years turns  
> out to be untenable when put into production, it needs to be fixed  
> sooner rather than later.  I am entirely willing to sacrifice rigid  
> API stability for the flexibility needed to fix things properly.
>
> And I am still a proponent of having an application be able to  
> indicate that a particular PEAR/Horde library needs to be a certain  
> version in order to work properly.  Not sure if that is still  
> something we are considering.
>
> michael
>
> -- 
> ___________________________________
> Michael Slusarz [slusarz at horde.org]
>
> -- 
> Horde developers mailing list
> Frequently Asked Questions: http://horde.org/faq/
> To unsubscribe, mail: dev-unsubscribe at lists.horde.org
>