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 garydgregory@gmail.com
 designates 209.85.214.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <ED9B9072-C3F5-40DF-91BD-E4F79E6D190D@it20one.at>
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>
	<ED9B9072-C3F5-40DF-91BD-E4F79E6D190D@it20one.at>
Date: Tue, 8 Oct 2013 16:54:17 -0400
Message-ID: 
 <CACZkXPxeNnj0r7s2tu0Sjs7eiQ8oJeRwzH7GwjZzaKU4N3zzaQ@mail.gmail.com>
Subject: Re: [DISCUSS] API compatibility policy
From: Gary Gregory <garydgregory@gmail.com>
To: Commons Developers List <dev@commons.apache.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Oct 8, 2013 at 4:50 PM, Siegfried Goeschl
<siegfried.goeschl@it20one.at> wrote:
> That's a reasonable style of versioning :)
>
> I had many issues with binary compatibilty with a commons-email release d=
ue to changing the return value from void to a this reference plus some mov=
ing of constants. You basically end up with either many restrictions or cre=
ating major releases

Then just create major releases! ;) Why would you not want to provide
BC? Why add to the jar hell problem? I, the developer, have no control
over how the API I provide will be used and distributed...

G

>
> Cheers,
>
> Siegfried Goeschl
>
>> Am 08.10.2013 um 12:40 schrieb Torsten Curdt <tcurdt@vafer.org>:
>>
>> Cannot remember which component from the top of my head - but it was
>> related to package name changes.
>>
>> My style of thinking: x.y.z
>>
>> x - no compatibility
>> y - source compatibility
>> z - binary compatibility
>>
>> is simple and makes sense.
>>
>> 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 ag=
ree.
>>
>> cheers,
>> Torsten
>>
>>
>>> On Tue, Oct 8, 2013 at 12:08 PM, Stefan Bodewig <bodewig@apache.org> wr=
ote:
>>>
>>>> On 2013-10-08, Emmanuel Bourg wrote:
>>>>
>>>> Le 07/10/2013 20:14, Benedikt Ritter a =C3=A9crit :
>>>
>>>>> - 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
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>


--=20
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
JUnit in Action, Second Edition
Spring Batch in Action
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

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