[dev] Horde release cycle

[Jan Schneider]

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.

Jan.

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