Merging horde and Horde_Core? was: Constructive Criticism/Venting

Zitat von Michael M Slusarz <[email protected]>:

> Quoting Michael J Rubinsky <[email protected]>:
>
>> Why does it REQUIRE a configuration change? This shouldn't be true  
>> for bug fix releases. At the very least, sensible defaults should  
>> be assumed for any new configuration switches added to Core. At the  
>> best, new configuration should be saved for point/feature releases.  
>> Even if we move Core into Horde, this shouldn't change.
>
> Nothing in Horde_Core works without configuration as provided by  
> horde (well... it doesn't require horde per se, but it requires  
> something that shares horde directory structure and configuration  
> file format.)
>
> The simple fact is that Horde_Core has nothing to do with every  
> other distributable package we have, since it is completely unusable  
> without installing Horde applications.  It conceptually doesn't make  
> any sense in that light.  Maybe other than an extreme adherence to  
> strict semantic versioning, but that alone shouldn't be a sufficient  
> reason.  i.e. whether a new API method bumps Horde_Core from 4.5.5  
> to 4.6.0 vs. the same change bumping horde 7.0.5 to 7.0.6 doesn't  
> matter to an application; since setting the correct dependency  
> version in an application works fine either way.

This is correct, horde cannot do without Horde_Core and vice versa.  
Having them in a single package would make at least as much sense as  
the current split.

I'm still with Michael R. for keeping those packages splitted though,  
for these reasons:
1) Michael is absolutely right that releasing Horde_Core is *much*  
easier and quicker than releasing horde. There is a reason that the  
current version is 2.12.
2) I feel like using strict semantic versioning makes us more  
disciplined. Bumping the minor version of Horde_Core is a no-brainer  
these days, while releasing minor version releases of horde still  
requires a coordinated release and a lot of work. It was especially  
you who pushed us onto the track of making it easier to require newer  
package versions in consumer code, which I'm really grateful for now.  
We still try to avoid requiring higher minor versions of application  
dependencies. But don't even think about requiring a higher library  
version anymore.
3) Stronger separation of code that is core of the horde ecosystem but  
consumed from all, or at least multiple applications, and code that  
belongs into the horde base application. I really had to get used to  
that distinction coming from the old horde-covers-all-core-code  
methodology, but it feels much cleaner now this way.

>>> Horde_Core is worthless without horde and vice versa.  We don't  
>>> gain anything from keeping them separate other than unneeded  
>>> complexity.
>>
>> With the exception of the points I made above, I agree. Apropos  
>> nothing, but wasn't Core originally your idea? To be clear, I'm not  
>> completely against this, but it means that "Horde" application  
>> releases would have to be able to occur more frequently.
>
> If it was my idea (I honestly can't remember), shame on me.  I admit  
> my mistake based on our experience working with the structure if  
> that is the case.
>
> michael
>
> ___________________________________
> Michael Slusarz [[email protected]]


-- 
Jan Schneider
The Horde Project
http://www.horde.org/
https://www.facebook.com/hordeproject

-- 
dev mailing list
Frequently Asked Questions: http://wiki.horde.org/FAQ
To unsubscribe, mail: [email protected]