[dev] Horde release cycle

[Michael M Slusarz]

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.

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]