[dev] Horde release cycle

[Gunnar Wrobel]

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

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

True, might be too much. We have other pages to keep track of our  
roadmap once we decided where to place the break.

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

Oh, then I'm simply happy :) Thanks for the feedback!

Gunnar

>
> Jan.
>
> -- 
> Do you need professional PHP or Horde consulting?
> http://horde.org/consulting/
>
> -- 
> Horde developers mailing list
> Frequently Asked Questions: http://horde.org/faq/
> To unsubscribe, mail: dev-unsubscribe at lists.horde.org

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