commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: [DISCUSS] API compatibility policy
Date Tue, 08 Oct 2013 20:54:17 GMT
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 due to changing
the return value from void to a this reference plus some moving of constants. You basically
end up with either many restrictions or creating 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 agree.
>>
>> cheers,
>> Torsten
>>
>>
>>> On Tue, Oct 8, 2013 at 12:08 PM, Stefan Bodewig <bodewig@apache.org> 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
>>> 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
>



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


Mime
View raw message