[dev] Horde release cycle

[Michael Rubinsky]

Quoting Gunnar Wrobel <wrobel at horde.org>:

> 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

+1 from me as well.

mike

The Horde Project (www.horde.org)
mrubinsk at horde.org