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 13:43:17 GMT
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


Mime
View raw message