[dev] Horde release cycle

Fri Mar 18 21:32:01 UTC 2011

Zitat von Chuck Hagenbuch <chuck at horde.org>:

> Quoting Jan Schneider <jan at horde.org>:
>
>> Zitat von Gunnar Wrobel <wrobel at horde.org>:
>>
>>>
>>> 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!
>>
>> There is something in this thread that hasn't been clearly decided  
>> yet. I'm quoting only part of it, please look up the archives for  
>> the complete thread.
>>
>> How long do we support major versions with security fixes?
>>
>> This is tightly connected to the question of how many branches we  
>> want to maintain. Two approaches have been brought up in this thread:
>>
>> 1) Provide security fixes for at least 18 months.
>> or
>> 2) Provide security fixes for the most recent two major versions.
>>
>> Assuming two extreme scenarios, these would be the consequences:
>>
>> We break BC 3 times in a row and thus released 3 major versions in a row:
>> 1) We are going to maintain up to 4 branches.
>> or
>> 2) We are going to provide security fixes for no longer than 12 months.
>>
>> We don't break BC 3 times in a row and thus released 3 minor  
>> versions in a row:
>> 1) We are going to maintain only 2 branches.
>> or
>> 2) We are going to provide security fixes for eternity.
>>
>> We could probably do a combination of both approaches, but I doubt  
>> this will make things clearer. I'm in favor of approach 2 because  
>> this is the only thing we really can promise with the limited  
>> developer resources we currently have IMO.
>
> I agree with Jan (security fixes for the most recent 2 major versions).

+1

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