commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Carman <ja...@carmanconsulting.com>
Subject Re: [DISCUSS] API compatibility policy
Date Tue, 08 Oct 2013 12:52:47 GMT
However, code modifications can be vetoed and nobody can overrule the veto.

On Tue, Oct 8, 2013 at 8:49 AM, Gary Gregory <garydgregory@gmail.com> wrote:
> On Tue, Oct 8, 2013 at 8:38 AM, James Carman <james@carmanconsulting.com>wrote:
>
>> Yes, we know we're allowed to do that, but folks seem to fight against
>> moving forward.
>>
>
> All you need is a [VOTE] and be done with it.
>
> Gary
>
>
>>
>> On Tue, Oct 8, 2013 at 8:35 AM, Gary Gregory <garydgregory@gmail.com>
>> wrote:
>> > You can break BC all you want when you do it in a NEW package. For
>> > example lang3.
>> >
>> > Gary
>> >
>> > On Oct 8, 2013, at 6:41, Torsten Curdt <tcurdt@vafer.org> wrote:
>> >
>> >> 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
>> >
>>
>> ---------------------------------------------------------------------
>> 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<http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> 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