commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <bode...@apache.org>
Subject Re: [DISCUSS] API compatibility policy
Date Tue, 08 Oct 2013 13:52:54 GMT
+1

Stefan

On 2013-10-08, James Carman wrote:

> Agreed.  I think we should come up with a naming convention.  The OSGi
> community (the maven bundle plugin) has adopted the notion that any
> package named "impl" or "internal" will not be exported.  Perhaps we
> set up that expectation to our users, too.  If it's in a package named
> as such, then it can change.  Use at your own risk!

> On Tue, Oct 8, 2013 at 9:35 AM, Phil Steitz <phil.steitz@gmail.com> wrote:
>> Sorry, got away from me before I finished. By "other Sw" I meant "other than when
someone wants to slip in a comparability break outside a major release." I agree with Luc
that we should allow ourselves to designate parts of the API as "internal" so subject to change
between major releases.  For [math] at least that would be a big help.

>> Sorry for the fat-fingering (again)

>>> On Oct 8, 2013, at 6:27 AM, Phil Steitz <phil.steitz@gmail.com> wrote:



>>>> On Oct 8, 2013, at 5:52 AM, James Carman <james@carmanconsulting.com>
wrote:

>>>> However, code modifications can be vetoed and nobody can overrule the veto.
>>> Honestly, I have not seen that much, other Sw What we need IMO is less talk and
more code.  Nobody has "blocked" or "vetoed" any new work on major release versions.  What
has been lacking is critical mass to really collaborate on the new stuff and fix bugs in the
stuff that has been released.  There are infinitely many natural numbers to work with.  Just
change package name, start a branch and go.  We should all realize of course that if our APIs
are too unstable and we don't back port bug fixes because all we want to do is "innovate"
people won't really use our stuff.

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


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