[dev] Horde release cycle

[Chuck Hagenbuch]

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

-chuck