[dev] Branches (again), Horde 4.1/5, recent IMAP changes

[Jan Schneider]

Zitat von Michael J Rubinsky <mrubinsk at horde.org>:

> Quoting Michael M Slusarz <slusarz at horde.org>:
>
> ...
>
>> this up again, but I will again raise my frustrations with working  
>> on IMP, especially as it relates to critical code changes.  *NO*  
>> other application relies so heavily on Horde-level code - e.g.  
>> MIME, IMAP, Text_Filtering code - and that makes it extremely  
>> difficult to fix certain items.  It takes me many times longer to  
>> fix an issue, simply because I have to go through the mental  
>> gymnastics of having to figure out how not to break existing APIs.   
>> IMP should not be less stable, or less able to be bugfixed, simply  
>> because it has more of a reliance on global Horde libraries but  
>> unfortunately, that is the case.
>
> What would you suggest the solution to this be? A BC break is a BC  
> break. While your frustration is well deserved and understood,  
> wouldn't this be trading ease of fixing bugs (making things easier  
> for you/us) for less API stability (something that would negatively  
> impact consumers of our code)?
>
> The only real solution I see to this while not bumping major version  
> numbers of the framework libraries (see below) is a willingness to  
> Horde's major version number sooner when these things are  
> fixed...though that would open up an entirely different can of worms.

We already agreed that the burden to release new major versions should  
be much lower now than before. It shouldn't be done thoughtlessly, but  
I have absolutely no problem with releasing Horde 5 a year after  
version 4, if we agree that this would be necessary.

> This also demonstrates a bit what I was saying in my previous email.  
> Strictly speaking, the framework libraries do not necessarily have  
> to be included in what we call "Horde 4" anymore (except maybe  
> Core). "H4" has lost a bit of it's meaning when compared to H3, IMO.
>
> This is how I think about it:
>
> An application's *external* interface needs to remain stable  
> throughout the major version number. OTOH, if a change in a  
> framework library requires a corresponding change in how an  
> application calls that library, or deals with it's values then  
> *that* change can be dealt with by bumping the version of the  
> component and bumping the minimum required version in the  
> application's package.xml file. This retains stability in the  
> framework library because we bumped the major version, but doesn't  
> hinder our developent efforts because the release wasn't delayed  
> until the next "Horde x" release.
>
> -- 
> mike
>
> The Horde Project (www.horde.org)
> mrubinsk at horde.org
>
> -- 
> Horde developers mailing list
> Frequently Asked Questions: http://horde.org/faq/
> To unsubscribe, mail: dev-unsubscribe at lists.horde.org


Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/