[dev] Horde release cycle

[Gunnar Wrobel]

Zitat von Jan Schneider <jan at horde.org>:

[snip]

>>>
>>> I don't see the need for a minimum wait time for breaking BC.  
>>> Breaking BC isn't something to be done without a lot of thougt.   
>>> If BC needs to be broken, there is a good reason for it (or we  
>>> shouldn't be breaking it). So, if there is a good enough reason  
>>> for us to break it, we shouldn't be hampered by an arbitrary wait  
>>> time.
>>>
>>>

[snip]

>>
>>                04/11 10/11 04/12 10/12 04/13 10/13
>>
>> FRAMEWORK_4_0   --bug---sec-|
>>                |
>> FRAMEWORK_4_1   |     --bug---sec-|
>>                |     |
>> FRAMEWORK_5     |     |     --bug---sec-|
>>                |     |     |
>> FRAMEWORK_6     |     |     |     --bug---sec-|
>>                |     |     |     |
>> master         ---dev---dev---dev---dev---dev----------------------
>>
>>
>> As far as I understood our discussion above we all agree on having  
>> a six month release cycle. Every six months there will be a release  
>> of a new major or minor version. As far as I can see - and I  
>> depicted my current understanding in the small graphic above - this  
>> would mean that each release would have a support window of one year.
>>
>> I don't see that as a problem as long as we are talking about minor  
>> versions. Assuming the picture above would not list "FRAMEWORK_5"  
>> and "FRAMEWORK_6" but "FRAMEWORK_4_2" and "FRAMEWORK_4_3" instead:  
>> Then the "Horde4" branch is suddenly supported over two and a half  
>> years. Maybe more in case the major version doesn't change.
>>
>> But what if we break BC frequently? There are people out there that  
>> code Horde based application - in fact this is what we target. If  
>> those applications would only get a guarantee of 1 year before  
>> major work might be necessary that feels like it is not enough.
>>
>> 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?
>
> With our limited resources, I don't think so. We could not break BC,  
> sure, but we all agreed we don't want this limitation anymore.
>
> The only solution I see is to add LTS releases to that equation. I  
> like the more formal approach of Ubuntu better than the  
> randomly-picked-stable-version of Kernel development, which is  
> harder to follow.
> But I don't see us having the man power for that at the moment.  
> Let's he how the release plan works that we're discussing here, and  
> what the feedback is. I have no idea how often we are going to break  
> BC in reality, how big those BC breaks are to pose a problem for  
> 3rd-party developers, and if developers are going to ask for longer  
> version support.
>

I do agree and I don't see much of a problem concerning LTS as long as  
we don't break BC every half year. But looking at our discussion this  
is not what any of us really wants.

But I feel I did not express my worries concerning the other side of  
the coin well enough.

You already mentioned above:

>>> 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).

This is what I consider to be the core of the Horde3 problem.

Let's assume I wouldn't be able to squeeze all the Kolab library  
rewrites into Horde4 that I feel are necessary at the moment. Not that  
unlikely actually :)

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?

I'm not saying that such things shouldn't happen without discussion.  
And often there will be ways around actually breaking BC which such  
discussion might identify. But what I'd like to have is some kind of  
way to be able to get a reliable time line for such things. Maybe if  
we have another "BC-breaks" wiki page that gets updated once a new  
issue which threatens BC comes up. Once the first item appears on that  
page we require ourselves to deal with the issue. Identify if it can  
be dealt with in a non-BC-breaking way. If not we decide when the next  
BC break will occur right then. Any BC-issues added to the page at a  
later point in time could only move that BC-break to a nearer release.  
Would something like that work?

Cheers,

Gunnar



-- 
Core Developer
The Horde Project

e: wrobel at horde.org
t: +49 700 6245 0000
w: http://www.horde.org

pgp: 9703 43BE
tweets: http://twitter.com/pardus_de
blog: http://log.pardus.de