[DISCUSS] Mission Statement for Commons...

classic Classic list List threaded Threaded
68 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] API compatibility policy

James Carman
I think the idea is to change the mindset.  There seems to be an almost
militant desire to maintain compatibility.  Yes, we have the version number
scheme, but some folks just never want to break compatibility it seems.
 This stalls innovation.  I don't want to debate every change, so setting
the expectations up-front is a good idea.

On Tuesday, October 8, 2013, Torsten Curdt 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 <[hidden email]<javascript:;>>
> 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: [hidden email]<javascript:;>
> > For additional commands, e-mail: [hidden email]<javascript:;>
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] API compatibility policy

Christian Grobmeier
On 8 Oct 2013, at 12:48, James Carman wrote:

> I think the idea is to change the mindset.  There seems to be an
> almost
> militant desire to maintain compatibility.  Yes, we have the version
> number
> scheme, but some folks just never want to break compatibility it
> seems.
> This stalls innovation.  I don't want to debate every change, so
> setting
> the expectations up-front is a good idea.

+1

> On Tuesday, October 8, 2013, Torsten Curdt wrote:
>> My style of thinking: x.y.z
>>
>> x - no compatibility
>> y - source compatibility
>> z - binary compatibility
>>
>> is simple and makes sense.

+1

I think its more or less semver: semver.org

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

Yes, and thats pretty bad because we cannot innovate any more.

I say: if we have people who want to maintain older version, go for it.
But please
let's stop blocking committers who want to do work a major change which
is not compatible.
If there are only people willing to work on the next major than to
maintain old versions
it is a bit sad, but thats life.

Christian





>>
>> cheers,
>> Torsten
>>
>>
>> On Tue, Oct 8, 2013 at 12:08 PM, Stefan Bodewig
>> <[hidden email]<javascript:;>>
>> 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:
>>> [hidden email]<javascript:;>
>>> For additional commands, e-mail:
>>> [hidden email]<javascript:;>
>>>
>>>
>>


---
http://www.grobmeier.de
@grobmeier
GPG: 0xA5CC90DB

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] API compatibility policy

garydgregory
In reply to this post by Torsten Curdt-3
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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] API compatibility policy

James Carman
Yes, we know we're allowed to do that, but folks seem to fight against
moving forward.

On Tue, Oct 8, 2013 at 8:35 AM, Gary Gregory <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] API compatibility policy

garydgregory
On Tue, Oct 8, 2013 at 8:38 AM, James Carman <[hidden email]>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 <[hidden email]>
> 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 <[hidden email]> 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 <[hidden email]>
> 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: [hidden email]
> >>> For additional commands, e-mail: [hidden email]
> >>>
> >>>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
E-Mail: [hidden email] | [hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] API compatibility policy

James Carman
However, code modifications can be vetoed and nobody can overrule the veto.

On Tue, Oct 8, 2013 at 8:49 AM, Gary Gregory <[hidden email]> wrote:

> On Tue, Oct 8, 2013 at 8:38 AM, James Carman <[hidden email]>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 <[hidden email]>
>> 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 <[hidden email]> 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 <[hidden email]>
>> 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: [hidden email]
>> >>> For additional commands, e-mail: [hidden email]
>> >>>
>> >>>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [hidden email]
>> > For additional commands, e-mail: [hidden email]
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
> --
> E-Mail: [hidden email] | [hidden email]
> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] API compatibility policy

Torsten Curdt-3
In reply to this post by garydgregory
http://www.youtube.com/watch?v=MqitYkILvnQ&feature=player_detailpage#t=63

Gary, really no offense - but I just could not resist :)
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] API compatibility policy

James Carman
That's kind of a mellow song from DMX.  He's not yelling as much as usual.

On Tue, Oct 8, 2013 at 8:53 AM, Torsten Curdt <[hidden email]> wrote:
> http://www.youtube.com/watch?v=MqitYkILvnQ&feature=player_detailpage#t=63
>
> Gary, really no offense - but I just could not resist :)

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] API compatibility policy

Phil Steitz
In reply to this post by James Carman


> On Oct 8, 2013, at 5:52 AM, James Carman <[hidden email]> 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 <[hidden email]> wrote:
>> On Tue, Oct 8, 2013 at 8:38 AM, James Carman <[hidden email]>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 <[hidden email]>
>>> 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 <[hidden email]> 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 <[hidden email]>
>>> 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: [hidden email]
>>>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>
>>
>> --
>> E-Mail: [hidden email] | [hidden email]
>> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] API compatibility policy

James Carman
The goal is to level set, so that we don't run into this stuff.

On Tue, Oct 8, 2013 at 9:27 AM, Phil Steitz <[hidden email]> wrote:

>
>
>> On Oct 8, 2013, at 5:52 AM, James Carman <[hidden email]> 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 <[hidden email]> wrote:
>>> On Tue, Oct 8, 2013 at 8:38 AM, James Carman <[hidden email]>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 <[hidden email]>
>>>> 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 <[hidden email]> 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 <[hidden email]>
>>>> 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: [hidden email]
>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>> --
>>> E-Mail: [hidden email] | [hidden email]
>>> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] API compatibility policy

Phil Steitz
In reply to this post by Phil Steitz
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 <[hidden email]> wrote:
>
>
>
>> On Oct 8, 2013, at 5:52 AM, James Carman <[hidden email]> 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 <[hidden email]> wrote:
>>> On Tue, Oct 8, 2013 at 8:38 AM, James Carman <[hidden email]>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 <[hidden email]>
>>>> 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 <[hidden email]> 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 <[hidden email]>
>>>> 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: [hidden email]
>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>> --
>>> E-Mail: [hidden email] | [hidden email]
>>> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] API compatibility policy

James Carman
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 <[hidden email]> 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 <[hidden email]> wrote:
>>
>>
>>
>>> On Oct 8, 2013, at 5:52 AM, James Carman <[hidden email]> 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 <[hidden email]> wrote:
>>>> On Tue, Oct 8, 2013 at 8:38 AM, James Carman <[hidden email]>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 <[hidden email]>
>>>>> 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 <[hidden email]> 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 <[hidden email]>
>>>>> 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: [hidden email]
>>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>> --
>>>> E-Mail: [hidden email] | [hidden email]
>>>> 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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] API compatibility policy

James Carman
In reply to this post by Emmanuel Bourg-3
Another concept I'd like to bring up is the fascination we seem to
have with protecting the users from being blithering idiots.  We
cannot protect them from themselves completely.  At some point, we
have to give them the benefit of the doubt that they're not complete
morons.  If they do indeed do something as stupid as relying upon type
inference in a case where it's clearly not applicable, then so be it.
They'll get a ClassCastException and figure it out in short order.

On Tue, Oct 8, 2013 at 4:55 AM, Emmanuel Bourg <[hidden email]> 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. This is an area
> where Guava is clearly not a good example, they deprecate and remove
> stuff frequently. Every time I update the Debian package for Guava I
> know this will break reverse dependencies, I have to fix it and convince
> the upstream projects to upgrade as well. On the other hand updating a
> Commons component is just a breeze.
>
> That being said, I think we are too strict on the compatibility rules.
> Some incompatible changes are much less risky than others. For example,
> adding a new method in an interface released less than 6 months ago
> shouldn't be vetoed, but renaming public methods in a code that has been
> in the wild for years shouldn't happen.
>
> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] API compatibility policy

Stefan Bodewig
In reply to this post by James Carman
+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 <[hidden email]> 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 <[hidden email]> wrote:



>>>> On Oct 8, 2013, at 5:52 AM, James Carman <[hidden email]> 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 <[hidden email]> wrote:
>>>>> On Tue, Oct 8, 2013 at 8:38 AM, James Carman <[hidden email]>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 <[hidden email]>
>>>>>> 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 <[hidden email]> 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 <[hidden email]>
>>>>>> 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: [hidden email]
>>>>>>>>> For additional commands, e-mail: [hidden email]

>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>> For additional commands, e-mail: [hidden email]

>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>> For additional commands, e-mail: [hidden email]


>>>>> --
>>>>> E-Mail: [hidden email] | [hidden email]
>>>>> 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: [hidden email]
>>>> For additional commands, e-mail: [hidden email]


>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]


> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] API compatibility policy

Emmanuel Bourg-3
In reply to this post by James Carman
Le 08/10/2013 15:46, James Carman a écrit :
> Another concept I'd like to bring up is the fascination we seem to
> have with protecting the users from being blithering idiots.

That's not the issue. We want to avoid unresolvable incompatibilities in
transitive dependencies. Our components are used by many projects, an
incompatibility could render impossible the use of two components
together, and you are stuck until the components are updated to use the
same version of the common dependency.

ASM and BouncyCastle are two examples of widely used projects that don't
care at all about the compatibilities, and this is causing pain and
wasting time to a lot of smart people.

Emmanuel Bourg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] API compatibility policy

James Carman
On Tue, Oct 8, 2013 at 10:04 AM, Emmanuel Bourg <[hidden email]> wrote:

>
> That's not the issue. We want to avoid unresolvable incompatibilities in
> transitive dependencies. Our components are used by many projects, an
> incompatibility could render impossible the use of two components
> together, and you are stuck until the components are updated to use the
> same version of the common dependency.
>
> ASM and BouncyCastle are two examples of widely used projects that don't
> care at all about the compatibilities, and this is causing pain and
> wasting time to a lot of smart people.
>

I think you misunderstand my intent.  We have left out features before
(ones that folks blogged about and said they liked) because a user
could do something stupid with it.

What you're talking about is "jar hell" and we have already addressed
that with our naming convention for major release bumps (changing
artifactId and package name).  I'm cool with that idea and I think
it's a pretty good approach.  I don't see anyone else doing it, which
is interesting.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] API compatibility policy

Phil Steitz


> On Oct 8, 2013, at 7:08 AM, James Carman <[hidden email]> wrote:
>
>> On Tue, Oct 8, 2013 at 10:04 AM, Emmanuel Bourg <[hidden email]> wrote:
>>
>> That's not the issue. We want to avoid unresolvable incompatibilities in
>> transitive dependencies. Our components are used by many projects, an
>> incompatibility could render impossible the use of two components
>> together, and you are stuck until the components are updated to use the
>> same version of the common dependency.
>>
>> ASM and BouncyCastle are two examples of widely used projects that don't
>> care at all about the compatibilities, and this is causing pain and
>> wasting time to a lot of smart people.
>
> I think you misunderstand my intent.  We have left out features before
> (ones that folks blogged about and said they liked) because a user
> could do something stupid with it.
>
> What you're talking about is "jar hell" and we have already addressed
> that with our naming convention for major release bumps (changing
> artifactId and package name).  I'm cool with that idea and I think
> it's a pretty good approach.  I don't see anyone else doing it, which
> is interesting.
>
I agree that the policy we have now to change package names is reasonable, but it has two drawbacks, one for us and one for users.  For us, it forces us to branch and cut a new major release each time we want/need to release something with a compat break.  For users, it forces them to redo all of their imports and swallow whatever other refactoring we have thrown in to the major release.  I think it makes sense to relax a bit and allow

0) some kind of annotation or naming scheme that allows us to mark classes as "internal"
1) a way to judge some compat breaks even outside the stuff in 0) as "minor" and allow them between major releases.

In theory Gump and downstream packaging tools could be used to verify 1), as well as lots of notification / time for comment.  I am not sure fixed rules could be defined for it though.  We have actually done it a couple of times in [math] and never had anyone scream (though there have been some complaints about API stability in general - which would somewhat ironically likely be improved if we allowed ourselves a little leeway in 0) and 1))

Phil
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] API compatibility policy

James Carman
Okay, so what I'm hearing is that we want to relax our "no API breaks
within a major release" policy.  Also, it sounds like we need to come
up with the naming convention where we can rope off parts of our API
as implementation details and they're not to be relied upon by outside
parties (they may do so at their own peril).

On Tue, Oct 8, 2013 at 12:22 PM, Phil Steitz <[hidden email]> wrote:

>
>
>> On Oct 8, 2013, at 7:08 AM, James Carman <[hidden email]> wrote:
>>
>>> On Tue, Oct 8, 2013 at 10:04 AM, Emmanuel Bourg <[hidden email]> wrote:
>>>
>>> That's not the issue. We want to avoid unresolvable incompatibilities in
>>> transitive dependencies. Our components are used by many projects, an
>>> incompatibility could render impossible the use of two components
>>> together, and you are stuck until the components are updated to use the
>>> same version of the common dependency.
>>>
>>> ASM and BouncyCastle are two examples of widely used projects that don't
>>> care at all about the compatibilities, and this is causing pain and
>>> wasting time to a lot of smart people.
>>
>> I think you misunderstand my intent.  We have left out features before
>> (ones that folks blogged about and said they liked) because a user
>> could do something stupid with it.
>>
>> What you're talking about is "jar hell" and we have already addressed
>> that with our naming convention for major release bumps (changing
>> artifactId and package name).  I'm cool with that idea and I think
>> it's a pretty good approach.  I don't see anyone else doing it, which
>> is interesting.
>>
> I agree that the policy we have now to change package names is reasonable, but it has two drawbacks, one for us and one for users.  For us, it forces us to branch and cut a new major release each time we want/need to release something with a compat break.  For users, it forces them to redo all of their imports and swallow whatever other refactoring we have thrown in to the major release.  I think it makes sense to relax a bit and allow
>
> 0) some kind of annotation or naming scheme that allows us to mark classes as "internal"
> 1) a way to judge some compat breaks even outside the stuff in 0) as "minor" and allow them between major releases.
>
> In theory Gump and downstream packaging tools could be used to verify 1), as well as lots of notification / time for comment.  I am not sure fixed rules could be defined for it though.  We have actually done it a couple of times in [math] and never had anyone scream (though there have been some complaints about API stability in general - which would somewhat ironically likely be improved if we allowed ourselves a little leeway in 0) and 1))
>
> Phil
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] API compatibility policy

garydgregory
In reply to this post by James Carman
On Oct 8, 2013, at 10:09, James Carman <[hidden email]> wrote:

> On Tue, Oct 8, 2013 at 10:04 AM, Emmanuel Bourg <[hidden email]> wrote:
>>
>> That's not the issue. We want to avoid unresolvable incompatibilities in
>> transitive dependencies. Our components are used by many projects, an
>> incompatibility could render impossible the use of two components
>> together, and you are stuck until the components are updated to use the
>> same version of the common dependency.
>>
>> ASM and BouncyCastle are two examples of widely used projects that don't
>> care at all about the compatibilities, and this is causing pain and
>> wasting time to a lot of smart people.
>
> I think you misunderstand my intent.  We have left out features before
> (ones that folks blogged about and said they liked) because a user
> could do something stupid with it.
>
> What you're talking about is "jar hell" and we have already addressed
> that with our naming convention for major release bumps (changing
> artifactId and package name).  I'm cool with that idea and I think
> it's a pretty good approach.  I don't see anyone else doing it, which
> is interesting.
>

Yep, our approach works. You cannot be kind of binary compatible, it's
all or nothing. I do like the idea of internal package names like
Eclipse does. This would not stop me from hacking my way in there but
at least I should not be surprised if a minor version breaks internal
binary compat.

Gary

> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] API compatibility policy

garydgregory
In reply to this post by James Carman
The only relaxing I could see is for code in internal packages.

Gary

On Oct 8, 2013, at 12:28, James Carman <[hidden email]> wrote:

> Okay, so what I'm hearing is that we want to relax our "no API breaks
> within a major release" policy.  Also, it sounds like we need to come
> up with the naming convention where we can rope off parts of our API
> as implementation details and they're not to be relied upon by outside
> parties (they may do so at their own peril).
>
> On Tue, Oct 8, 2013 at 12:22 PM, Phil Steitz <[hidden email]> wrote:
>>
>>
>>> On Oct 8, 2013, at 7:08 AM, James Carman <[hidden email]> wrote:
>>>
>>>> On Tue, Oct 8, 2013 at 10:04 AM, Emmanuel Bourg <[hidden email]> wrote:
>>>>
>>>> That's not the issue. We want to avoid unresolvable incompatibilities in
>>>> transitive dependencies. Our components are used by many projects, an
>>>> incompatibility could render impossible the use of two components
>>>> together, and you are stuck until the components are updated to use the
>>>> same version of the common dependency.
>>>>
>>>> ASM and BouncyCastle are two examples of widely used projects that don't
>>>> care at all about the compatibilities, and this is causing pain and
>>>> wasting time to a lot of smart people.
>>>
>>> I think you misunderstand my intent.  We have left out features before
>>> (ones that folks blogged about and said they liked) because a user
>>> could do something stupid with it.
>>>
>>> What you're talking about is "jar hell" and we have already addressed
>>> that with our naming convention for major release bumps (changing
>>> artifactId and package name).  I'm cool with that idea and I think
>>> it's a pretty good approach.  I don't see anyone else doing it, which
>>> is interesting.
>> I agree that the policy we have now to change package names is reasonable, but it has two drawbacks, one for us and one for users.  For us, it forces us to branch and cut a new major release each time we want/need to release something with a compat break.  For users, it forces them to redo all of their imports and swallow whatever other refactoring we have thrown in to the major release.  I think it makes sense to relax a bit and allow
>>
>> 0) some kind of annotation or naming scheme that allows us to mark classes as "internal"
>> 1) a way to judge some compat breaks even outside the stuff in 0) as "minor" and allow them between major releases.
>>
>> In theory Gump and downstream packaging tools could be used to verify 1), as well as lots of notification / time for comment.  I am not sure fixed rules could be defined for it though.  We have actually done it a couple of times in [math] and never had anyone scream (though there have been some complaints about API stability in general - which would somewhat ironically likely be improved if we allowed ourselves a little leeway in 0) and 1))
>>
>> Phil
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

1234