Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (athena.apache.org: domain of grobmeier@gmail.com
 designates 209.85.215.172 as permitted sender)
From: "Christian Grobmeier" <grobmeier@gmail.com>
To: "Commons Developers List" <dev@commons.apache.org>
Subject: Re: [DISCUSS] API compatibility policy
Date: Tue, 08 Oct 2013 14:11:23 +0200
Message-ID: <BC570A91-1874-47C0-B96F-222C9FE32B0C@gmail.com>
In-Reply-To: 
 <CALznzY6sJxCRztmVyP2UMjiSJki95Ui+Xy+56+WA-fNccW6spw@mail.gmail.com>
References: 
 <CALznzY7FDoRUnAd-MyrDBfddKqymQaCwPiyZBvfEApn-XMFFqg@mail.gmail.com>
 <ADD8565E-1C42-45A8-9163-F9E12C9D4CA5@gmail.com>
 <CALznzY5tnaRjN9q87Xrxj4hqWSmsSAnEx1J=CJoKQQRHTz4kgQ@mail.gmail.com>
 <CAB917R+tWS8BdteWOa-d9bpm1mBV2HE8WrfAu1MgyhcKKHCzmA@mail.gmail.com>
 <5253C871.2050307@apache.org> <8738oc5b31.fsf@v35516.1blu.de>
 <CAEQx=x=Jgf1PAFuWzOvXZBHTdnktXFd1cZ+6qw0U1h72MPUfAA@mail.gmail.com>
 <CALznzY6sJxCRztmVyP2UMjiSJki95Ui+Xy+56+WA-fNccW6spw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

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