commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [DISCUSS] API compatibility policy
Date Sun, 13 Oct 2013 22:39:54 GMT
On 9 October 2013 05:14, Siegfried Goeschl <siegfried.goeschl@it20one.at> wrote:
> Hi Gary,
>
> A new major release requires a new package name, site, build and so on - think of commons-lang
v1,2,3

Huh?

A major release does not imply an API break, though the reverse is true.

> Cheers,
>
> Siegfried Goeschl
>
>> Am 08.10.2013 um 22:54 schrieb Gary Gregory <garydgregory@gmail.com>:
>>
>> 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
>>
>
> ---------------------------------------------------------------------
> 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


Mime
View raw message