Re: Constructive Criticism/Venting

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.

>> 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]]

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