commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christian Grobmeier" <grobme...@gmail.com>
Subject Re: [DISCUSS] API compatibility policy
Date Tue, 08 Oct 2013 12:11:23 GMT
On 8 Oct 2013, at 12:48, James Carman wrote:

> I think the idea is to change the mindset.  There seems to be an 
> almost
> militant desire to maintain compatibility.  Yes, we have the version 
> number
> scheme, but some folks just never want to break compatibility it 
> seems.
> This stalls innovation.  I don't want to debate every change, so 
> setting
> the expectations up-front is a good idea.

+1

> On Tuesday, October 8, 2013, Torsten Curdt wrote:
>> My style of thinking: x.y.z
>>
>> x - no compatibility
>> y - source compatibility
>> z - binary compatibility
>>
>> is simple and makes sense.

+1

I think its more or less semver: semver.org

>> It's OK to put some burden on the users when upgrading - as long as 
>> the
>> expectations are set correctly.
>> But I am pretty sure we discussed that before and some people did not
>> agree.

Yes, and thats pretty bad because we cannot innovate any more.

I say: if we have people who want to maintain older version, go for it. 
But please
let's stop blocking committers who want to do work a major change which 
is not compatible.
If there are only people willing to work on the next major than to 
maintain old versions
it is a bit sad, but thats life.

Christian





>>
>> cheers,
>> Torsten
>>
>>
>> On Tue, Oct 8, 2013 at 12:08 PM, Stefan Bodewig 
>> <bodewig@apache.org<javascript:;>>
>> wrote:
>>
>>> On 2013-10-08, Emmanuel Bourg wrote:
>>>
>>>> Le 07/10/2013 20:14, Benedikt Ritter a écrit :
>>>
>>>>> - loosen API compatibility policy?
>>>
>>>> This topic alone deserves its own thread I think.
>>>
>>>> Ensuring binary/source compatibility is very important.
>>>
>>> +1
>>>
>>> I guess I've done too much ruby with "every bundle update runs the 
>>> risk
>>> of breaking everything" lately.  I really value the stability 
>>> commons
>>> provides.
>>>
>>> That being said, I'm sure there are cases where our policy seems
>>> stricter than it needs to be - even though I haven't seen a really
>>> difficult case in the one component I contribute to.
>>>
>>> Stefan
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: 
>>> dev-unsubscribe@commons.apache.org<javascript:;>
>>> For additional commands, e-mail: 
>>> dev-help@commons.apache.org<javascript:;>
>>>
>>>
>>


---
http://www.grobmeier.de
@grobmeier
GPG: 0xA5CC90DB

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message