[dev] Horde release cycle

[Ben Klang]

On Jan 26, 2011, at 7:23 AM, Jan Schneider wrote:
>>> Following this reasoning I would say we should really avoid breaking BC ... in fact ... wasn't Horde3 a good model? ;)
>>> 
>>> Joking aside: I feel this is the critical point that we need to solve. Is there a model that allows us to provide both the users as well as the developers - custom app devs and us alike - to have a reliable scheme that suits the specific needs of our project?

As a quick aside, I don't think we should be too quick to dismiss how great the API stability in Horde 3 was.  It was just too much of a good thing.


>>>>> Breaking BC isn't something to be done without a lot of thought.  If BC needs to be broken, there is a good reason for it (or we shouldn't be breaking it).
>> 
>> So in half a year I raise my lonely voice: "Hey, what about breaking BC? Wouldn't that be fun to do?". And of course I get a: "Nope! Not a chance!". Reasonable. What about April 2012? Same thing? 2013?

This is why I want to set a policy for minimum time between breaking BC.  It does not have to be set in stone, but it does set expectations.  We have to balance the needs of internal development with the needs of external development.  My opinion is that we need to promise consumers of our library something to justify their investment in our code.  Also, by establishing a timeline, we can tell Gunnar that he does have to wait to break BC for now...but only until June 2012.  And then we document whatever changes are backward incompatible and assist developers in migrating.

All of this effort is only important if Horde wants to attract external developers.  I see that as a hidden asset of the Horde project itself -- there are lots of other groupware packages out there but Horde is better suited than most for 3rd parties who want to integrate tightly into our apps.  This may not be our primary objective.  If we need to be more concerned with Groupware features than API stability maybe we do not put as much effort into our BC promise.  It's a matter of priorities.


/BAK/