[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

sebb-2-2
On 8 October 2013 17:36, Gary Gregory <[hidden email]> wrote:

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

Yes and no.

Yes, one can say unambiguously that a particular change is - or is not
- binary compatible according to the Java compatibility rules.

But it may still be OK to break binary compatibility without package
renames if the likelihood of it affecting end users is extremely low.

I think the way to approach binary incompatibility is as follows:
- check whether it's really necessary to break compatibility;
sometimes it happens by accident and can be fixed
- if the break really is necessary, evaluate how likely it is to
affect 3rd party code.

Depending on the severity of the break, it may be necessary to change
package name/Maven coordinates, or it may just require a warning in
the release notes.

It's not always easy to get this right, which is where it's useful to
have a community of experienced developers.

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

+1

But it's not always obvious initially which classes are which.

[Also of course one should start by making everything private
(especially mutable fields) and only increasing visibility as needed.]

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

---------------------------------------------------------------------
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 2:11 PM, sebb <[hidden email]> wrote:

> On 8 October 2013 17:36, Gary Gregory <[hidden email]> wrote:
>> 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.
>
> Yes and no.

You can't tell me with a straight face that binary compatibility is
not a strict true/false attribute ;)

While I agree with the overall feel of your message, my experience
makes be love BC. Even small apps that end up with layers of 3rd party
jar deps leads you immediately to jar hell if there is no binary
compatibility within packages. This is why our change of package name
(and maven coords) guideline works so well.

Sure, some corner method is a tucked away class may never be used
outside the jar, but, if it's public, don't break it. You just do not
know what call sites are going to do.

I have no problem bumping major versions., package names, and Maven
coords in order to keep a project evolving at 21st century speeds.
This is probably why I am OK with a stricter BC definition.

Gary


>
> Yes, one can say unambiguously that a particular change is - or is not
> - binary compatible according to the Java compatibility rules.
>
> But it may still be OK to break binary compatibility without package
> renames if the likelihood of it affecting end users is extremely low.
>
> I think the way to approach binary incompatibility is as follows:
> - check whether it's really necessary to break compatibility;
> sometimes it happens by accident and can be fixed
> - if the break really is necessary, evaluate how likely it is to
> affect 3rd party code.
>
> Depending on the severity of the break, it may be necessary to change
> package name/Maven coordinates, or it may just require a warning in
> the release notes.
>
> It's not always easy to get this right, which is where it's useful to
> have a community of experienced developers.
>
>> 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.
>
> +1
>
> But it's not always obvious initially which classes are which.
>
> [Also of course one should start by making everything private
> (especially mutable fields) and only increasing visibility as needed.]
>
>> 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]
>>
>
> ---------------------------------------------------------------------
> 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
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] API compatibility policy

sebb-2-2
On 8 October 2013 21:11, Gary Gregory <[hidden email]> wrote:

> On Tue, Oct 8, 2013 at 2:11 PM, sebb <[hidden email]> wrote:
>> On 8 October 2013 17:36, Gary Gregory <[hidden email]> wrote:
>>> 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.
>>
>> Yes and no.
>
> You can't tell me with a straight face that binary compatibility is
> not a strict true/false attribute ;)
>
> While I agree with the overall feel of your message, my experience
> makes be love BC. Even small apps that end up with layers of 3rd party
> jar deps leads you immediately to jar hell if there is no binary
> compatibility within packages. This is why our change of package name
> (and maven coords) guideline works so well.
>
> Sure, some corner method is a tucked away class may never be used
> outside the jar, but, if it's public, don't break it. You just do not
> know what call sites are going to do.

Each incompatibility needs to be decided on its merits.
For example, if a class or method is clearly documented as internal or
experimental, then anyone that relies on it should not be surprised if
problems occur. Just the same as if one uses a class from a sun.*
package.

There are other examples where the field or code may be part of the
public API, but nevertheless making use of it is clearly wrong.
For example, writing to an entry in a protected final array which
contains constants. (The array should have been private with an
accessor).
I'm sure there have been other cases.

> I have no problem bumping major versions., package names, and Maven
> coords in order to keep a project evolving at 21st century speeds.

I prefer that to jar hell and/or stagnation, however the downside is
additional work downstream.

The choice is not always black/white.

> This is probably why I am OK with a stricter BC definition.
>
> Gary
>
>
>>
>> Yes, one can say unambiguously that a particular change is - or is not
>> - binary compatible according to the Java compatibility rules.
>>
>> But it may still be OK to break binary compatibility without package
>> renames if the likelihood of it affecting end users is extremely low.
>>
>> I think the way to approach binary incompatibility is as follows:
>> - check whether it's really necessary to break compatibility;
>> sometimes it happens by accident and can be fixed
>> - if the break really is necessary, evaluate how likely it is to
>> affect 3rd party code.
>>
>> Depending on the severity of the break, it may be necessary to change
>> package name/Maven coordinates, or it may just require a warning in
>> the release notes.
>>
>> It's not always easy to get this right, which is where it's useful to
>> have a community of experienced developers.
>>
>>> 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.
>>
>> +1
>>
>> But it's not always obvious initially which classes are which.
>>
>> [Also of course one should start by making everything private
>> (especially mutable fields) and only increasing visibility as needed.]
>>
>>> 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]
>>>
>>
>> ---------------------------------------------------------------------
>> 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
> 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: [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

Siegfried Goeschl
In reply to this post by Torsten Curdt-3
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

Cheers,

Siegfried Goeschl

> Am 08.10.2013 um 12:40 schrieb Torsten Curdt <[hidden email]>:
>
> 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

garydgregory
On Tue, Oct 8, 2013 at 4:50 PM, Siegfried Goeschl
<[hidden email]> 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 <[hidden email]>:
>>
>> 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]
>



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

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] API compatibility policy

Paul Benedict
A good resource if you didn't know it existed:
http://commons.apache.org/releases/versioning.html


On Tue, Oct 8, 2013 at 3:54 PM, Gary Gregory <[hidden email]> wrote:

> On Tue, Oct 8, 2013 at 4:50 PM, Siegfried Goeschl
> <[hidden email]> 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 <[hidden email]>:
> >>
> >> 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]
> >
>
>
>
> --
> E-Mail: [hidden email] | [hidden email]
> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Cheers,
Paul
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] API compatibility policy

Siegfried Goeschl
In reply to this post by garydgregory
Hi Gary,

A new major release requires a new package name, site, build and so on - think of commons-lang v1,2,3

Cheers,

Siegfried Goeschl

> Am 08.10.2013 um 22:54 schrieb Gary Gregory <[hidden email]>:
>
> On Tue, Oct 8, 2013 at 4:50 PM, Siegfried Goeschl
> <[hidden email]> 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 <[hidden email]>:
>>>
>>> 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]
>
>
>
> --
> E-Mail: [hidden email] | [hidden email]
> 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: [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

sebb-2-2
On 9 October 2013 05:14, Siegfried Goeschl <[hidden email]> 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 <[hidden email]>:
>>
>> On Tue, Oct 8, 2013 at 4:50 PM, Siegfried Goeschl
>> <[hidden email]> 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 <[hidden email]>:
>>>>
>>>> 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]
>>
>>
>>
>> --
>> E-Mail: [hidden email] | [hidden email]
>> 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: [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