[dev] Horde release cycle

[Jan Schneider]

Zitat von Gunnar Wrobel <wrobel at horde.org>:

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

I'm not sure if we need a formal wiki page for that, though it  
wouldn't hurt either. But that's generally the process I had in mind  
when and how to decide whether to break BC.
Someone identifies a possible BC break necessity. We start a dicussion  
about how to avoid it. If that's not possible, we target a release for  
the break, most probably the next release. The decision will probably  
influenced by the importance of the break and the rate or BC breaking  
releases in the past.

Jan.

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