[ALL] About binary compatibility

classic Classic list List threaded Threaded
58 messages Options
123
Reply | Threaded
Open this post in threaded view
|

[ALL] About binary compatibility

Benedikt Ritter-4
Hi,

we do seem to have different opinions when it comes to binary compatibility
and how it should be handled. Usually we would say "this should be decided
on a component basis". However this discussion is coming up again and again
and I think we should try the impossible and agree on something that we can
document.

So here is my view on the topic:

- since our components are depended upon by a lot of projects, we need to
take special care regarding compatibility.
- we must not break BC in a release that could collide with an earlier
version. In other words, when we break BC, we have to change package and
maven coordinates.
- BUT since we're all doing this on our spare time, there is no need to
hold on old APIs just for the sake of it. For this reason, BC may be broken
any time, if the steps above a followed and it has been discussed on the
ML. Fixes can always be backported to old releases, by people who need it.
- If there are committers who are willing to work on old version and
committers who want to work on API redesigns, we can branch and work in
paralell.
- Changing the Java Language requirement does not break BC and can
therefore be done without pumping the major version.

What is your view on the topic?

Benedikt
Reply | Threaded
Open this post in threaded view
|

Re: [ALL] About binary compatibility

Bernd Eckenfels
Hello,

Unhappy with it but agreeing that your definition sounds like it should apply.

I would vote for always bumping at least the minor version when requiring newer dependencies (including Java Version). Strictly speaking semver would require a major version but with our policy of using new package names for major versions that would annoy lots of users.

And we really really need to avoid VFS-style release congestions (because backporting becomes prohibitively painful).

Gruss
Bernd

--
http://bernd.eckenfels.net

-----Original Message-----
From: Benedikt Ritter <[hidden email]>
To: Commons Developers List <[hidden email]>
Sent: Do., 02 Juni 2016 22:43
Subject: [ALL] About binary compatibility

Hi,

we do seem to have different opinions when it comes to binary compatibility
and how it should be handled. Usually we would say "this should be decided
on a component basis". However this discussion is coming up again and again
and I think we should try the impossible and agree on something that we can
document.

So here is my view on the topic:

- since our components are depended upon by a lot of projects, we need to
take special care regarding compatibility.
- we must not break BC in a release that could collide with an earlier
version. In other words, when we break BC, we have to change package and
maven coordinates.
- BUT since we're all doing this on our spare time, there is no need to
hold on old APIs just for the sake of it. For this reason, BC may be broken
any time, if the steps above a followed and it has been discussed on the
ML. Fixes can always be backported to old releases, by people who need it.
- If there are committers who are willing to work on old version and
committers who want to work on API redesigns, we can branch and work in
paralell.
- Changing the Java Language requirement does not break BC and can
therefore be done without pumping the major version.

What is your view on the topic?

Benedikt

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

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] About binary compatibility

garydgregory
In reply to this post by Benedikt Ritter-4
On Thu, Jun 2, 2016 at 1:42 PM, Benedikt Ritter <[hidden email]> wrote:

> Hi,
>
> we do seem to have different opinions when it comes to binary compatibility
> and how it should be handled. Usually we would say "this should be decided
> on a component basis". However this discussion is coming up again and again
> and I think we should try the impossible and agree on something that we can
> document.
>
> So here is my view on the topic:
>
> - since our components are depended upon by a lot of projects, we need to
> take special care regarding compatibility.
>
+1


> - we must not break BC in a release that could collide with an earlier
> version. In other words, when we break BC, we have to change package and
> maven coordinates.
>
+1


> - BUT since we're all doing this on our spare time, there is no need to
> hold on old APIs just for the sake of it. For this reason, BC may be broken
> any time, if the steps above a followed and it has been discussed on the
> ML. Fixes can always be backported to old releases, by people who need it.
>
+1


> - If there are committers who are willing to work on old version and
> committers who want to work on API redesigns, we can branch and work in
> paralell.
>
+1


> - Changing the Java Language requirement does not break BC and can
> therefore be done without pumping the major version.
>
+1

I would also be OK to actually bump the major release version of a
component when the Java plaform changes _without_ changing the package
name. This would just be a nice indication that something important have
changed that WILL break applications stuck on older JREs.

Nice email. You have beaten me to the punch!

Gary


> What is your view on the topic?
>
> Benedikt
>



--
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: [ALL] About binary compatibility

Jörg Schaible
In reply to this post by Benedikt Ritter-4
Hi Benedikt,

Benedikt Ritter wrote:

> Hi,
>
> we do seem to have different opinions when it comes to binary
> compatibility and how it should be handled. Usually we would say "this
> should be decided on a component basis". However this discussion is coming
> up again and again and I think we should try the impossible and agree on
> something that we can document.
>
> So here is my view on the topic:
>
> - since our components are depended upon by a lot of projects, we need to
> take special care regarding compatibility.
> - we must not break BC in a release that could collide with an earlier
> version. In other words, when we break BC, we have to change package and
> maven coordinates.
> - BUT since we're all doing this on our spare time, there is no need to
> hold on old APIs just for the sake of it. For this reason, BC may be
> broken any time, if the steps above a followed and it has been discussed
> on the ML. Fixes can always be backported to old releases, by people who
> need it. - If there are committers who are willing to work on old version
> and committers who want to work on API redesigns, we can branch and work
> in paralell.
> - Changing the Java Language requirement does not break BC and can
> therefore be done without pumping the major version.
>
> What is your view on the topic?

+1

We need a fine balance between BC requirement and ongoing development and
you nicely summed it up.

Cheers,
Jörg


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

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] About binary compatibility

Emmanuel Bourg-3
In reply to this post by Benedikt Ritter-4
Le 2/06/2016 à 22:42, Benedikt Ritter a écrit :

> - since our components are depended upon by a lot of projects, we need to
> take special care regarding compatibility.

+1, thanks God Apache Commons isn't like Guava or BouncyCastle.


> - we must not break BC in a release that could collide with an earlier
> version. In other words, when we break BC, we have to change package and
> maven coordinates.

I tend to agree but I think some exceptions should be allowed:
* If the element affected by the BC issue was released very recently, we
should be able to roll out a new release changing it. For example if foo
1.3 added a protected method to a class, we should be able to make it
private in foo 1.3.1 if we release it shortly after (let's say less than
2 months after foo 1.3).
* If the API affected is just internal stuff not intended to be used
directly, it should be possible to change it.


> - BUT since we're all doing this on our spare time, there is no need to
> hold on old APIs just for the sake of it. For this reason, BC may be broken
> any time, if the steps above a followed and it has been discussed on the
> ML. Fixes can always be backported to old releases, by people who need it.

Ok but this can only work if our release process is simplified, because
backporting means publishing more releases


> - Changing the Java Language requirement does not break BC and can
> therefore be done without pumping the major version.

I agree, bumping the major version isn't mandatory in this case.

Emmanuel Bourg


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

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] About binary compatibility

Benedikt Ritter-4
Emmanuel Bourg <[hidden email]> schrieb am Do., 2. Juni 2016 um
23:26 Uhr:

> Le 2/06/2016 à 22:42, Benedikt Ritter a écrit :
>
> > - since our components are depended upon by a lot of projects, we need to
> > take special care regarding compatibility.
>
> +1, thanks God Apache Commons isn't like Guava or BouncyCastle.
>
>
> > - we must not break BC in a release that could collide with an earlier
> > version. In other words, when we break BC, we have to change package and
> > maven coordinates.
>
> I tend to agree but I think some exceptions should be allowed:
> * If the element affected by the BC issue was released very recently, we
> should be able to roll out a new release changing it. For example if foo
> 1.3 added a protected method to a class, we should be able to make it
> private in foo 1.3.1 if we release it shortly after (let's say less than
> 2 months after foo 1.3).
> * If the API affected is just internal stuff not intended to be used
> directly, it should be possible to change it.
>
>
> > - BUT since we're all doing this on our spare time, there is no need to
> > hold on old APIs just for the sake of it. For this reason, BC may be
> broken
> > any time, if the steps above a followed and it has been discussed on the
> > ML. Fixes can always be backported to old releases, by people who need
> it.
>
> Ok but this can only work if our release process is simplified, because
> backporting means publishing more releases
>

Great idea! Let's start a discussion about our release process right after
we have settled an agreement about the BC topic.


>
>
> > - Changing the Java Language requirement does not break BC and can
> > therefore be done without pumping the major version.
>
> I agree, bumping the major version isn't mandatory in this case.
>
> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [ALL] About binary compatibility

Benson Margulies
In reply to this post by garydgregory
I don't understand what's wrong with semantic versioning and keeping
the same maven coordinates. No sane person should be using RELEASE or
LATEST.

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

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] About binary compatibility

Benedikt Ritter-4
Hello Benson,

Benson Margulies <[hidden email]> schrieb am Do., 2. Juni 2016 um
23:36 Uhr:

> I don't understand what's wrong with semantic versioning and keeping
> the same maven coordinates. No sane person should be using RELEASE or
> LATEST.
>

The problem are transitive dependencies. Consider this example:

My-Project
 | -> A -> B -> C 1.2
 | -> D -> C 2.0

In this case my project depends directly on A and D. A depends on B which
depends on C in version 1.2. D depends on C in version 2.0. In this case I
have no control over the dependencies to C but my project will be broken at
run time, because C 1.2 and C 2.0 can not exist at once in the same
classpath.

Benedikt


> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [ALL] About binary compatibility

Benson Margulies
Dependency management cures this; if you don't want to pick up newer
versions, you can prevent it. Since dep management doesn't know about
ranges or semantic versioning, you need to then pay attention if you
want a compatible version that comes along.

I guess it's a question of which poison you prefer. If people here
prefer bumping artifactids and package names, so be it.


On Thu, Jun 2, 2016 at 6:01 PM, Benedikt Ritter <[hidden email]> wrote:

> Hello Benson,
>
> Benson Margulies <[hidden email]> schrieb am Do., 2. Juni 2016 um
> 23:36 Uhr:
>
>> I don't understand what's wrong with semantic versioning and keeping
>> the same maven coordinates. No sane person should be using RELEASE or
>> LATEST.
>>
>
> The problem are transitive dependencies. Consider this example:
>
> My-Project
>  | -> A -> B -> C 1.2
>  | -> D -> C 2.0
>
> In this case my project depends directly on A and D. A depends on B which
> depends on C in version 1.2. D depends on C in version 2.0. In this case I
> have no control over the dependencies to C but my project will be broken at
> run time, because C 1.2 and C 2.0 can not exist at once in the same
> classpath.
>
> Benedikt
>
>
>> ---------------------------------------------------------------------
>> 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: [ALL] About binary compatibility

James Carman
In reply to this post by Benson Margulies
You've been in karaf land for too long! ;)

On Thu, Jun 2, 2016 at 5:36 PM Benson Margulies <[hidden email]>
wrote:

> I don't understand what's wrong with semantic versioning and keeping
> the same maven coordinates. No sane person should be using RELEASE or
> LATEST.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [ALL] About binary compatibility

Benson Margulies
On Thu, Jun 2, 2016 at 6:04 PM, James Carman <[hidden email]> wrote:
> You've been in karaf land for too long! ;)

I took my team into OSGi to get away from these messes. Of course, we
got some other messes in their places.

>
> On Thu, Jun 2, 2016 at 5:36 PM Benson Margulies <[hidden email]>
> wrote:
>
>> I don't understand what's wrong with semantic versioning and keeping
>> the same maven coordinates. No sane person should be using RELEASE or
>> LATEST.
>>
>> ---------------------------------------------------------------------
>> 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: [ALL] About binary compatibility

James Carman
Yep, those pesky duplicate chains.
On Thu, Jun 2, 2016 at 6:05 PM Benson Margulies <[hidden email]>
wrote:

> On Thu, Jun 2, 2016 at 6:04 PM, James Carman <[hidden email]>
> wrote:
> > You've been in karaf land for too long! ;)
>
> I took my team into OSGi to get away from these messes. Of course, we
> got some other messes in their places.
>
> >
> > On Thu, Jun 2, 2016 at 5:36 PM Benson Margulies <[hidden email]>
> > wrote:
> >
> >> I don't understand what's wrong with semantic versioning and keeping
> >> the same maven coordinates. No sane person should be using RELEASE or
> >> LATEST.
> >>
> >> ---------------------------------------------------------------------
> >> 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: [ALL] About binary compatibility

garydgregory
In reply to this post by Emmanuel Bourg-3
On Thu, Jun 2, 2016 at 2:26 PM, Emmanuel Bourg <[hidden email]> wrote:

> Le 2/06/2016 à 22:42, Benedikt Ritter a écrit :
>
> > - since our components are depended upon by a lot of projects, we need to
> > take special care regarding compatibility.
>
> +1, thanks God Apache Commons isn't like Guava or BouncyCastle.
>
>
> > - we must not break BC in a release that could collide with an earlier
> > version. In other words, when we break BC, we have to change package and
> > maven coordinates.
>
> I tend to agree but I think some exceptions should be allowed:
> * If the element affected by the BC issue was released very recently, we
> should be able to roll out a new release changing it. For example if foo
> 1.3 added a protected method to a class, we should be able to make it
> private in foo 1.3.1 if we release it shortly after (let's say less than
> 2 months after foo 1.3).
>
-1

Timing is irrelevant. You cannot control what will end up in an app stack.
Once released, that's it unfortunately, otherwise, the door to jar hell is
open.

Gary


> * If the API affected is just internal stuff not intended to be used
> directly, it should be possible to change it.
>
>
> > - BUT since we're all doing this on our spare time, there is no need to
> > hold on old APIs just for the sake of it. For this reason, BC may be
> broken
> > any time, if the steps above a followed and it has been discussed on the
> > ML. Fixes can always be backported to old releases, by people who need
> it.
>
> Ok but this can only work if our release process is simplified, because
> backporting means publishing more releases
>
>
> > - Changing the Java Language requirement does not break BC and can
> > therefore be done without pumping the major version.
>
> I agree, bumping the major version isn't mandatory in this case.
>
> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> 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: [ALL] About binary compatibility

garydgregory
In reply to this post by Benedikt Ritter-4
On Thu, Jun 2, 2016 at 3:01 PM, Benedikt Ritter <[hidden email]> wrote:

> Hello Benson,
>
> Benson Margulies <[hidden email]> schrieb am Do., 2. Juni 2016 um
> 23:36 Uhr:
>
> > I don't understand what's wrong with semantic versioning and keeping
> > the same maven coordinates. No sane person should be using RELEASE or
> > LATEST.
> >
>
> The problem are transitive dependencies. Consider this example:
>
> My-Project
>  | -> A -> B -> C 1.2
>  | -> D -> C 2.0
>
> In this case my project depends directly on A and D. A depends on B which
> depends on C in version 1.2. D depends on C in version 2.0. In this case I
> have no control over the dependencies to C but my project will be broken at
> run time, because C 1.2 and C 2.0 can not exist at once in the same
> classpath.
>

For a fun example, I once had a server stack with dependencies on Apache
CXF and JBoss Teiid, 100's jars... lots of t-deps...

Gary


>
> Benedikt
>
>
> > ---------------------------------------------------------------------
> > 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: [ALL] About binary compatibility

Ralph Goers
In reply to this post by Benson Margulies
Dependency management does not cure this if C 1.2 and C 2.0 are not binary compatible. Code compiled with the 1.2 version will fail if those methods and classes are not in 2.0.

Ralph

> On Jun 2, 2016, at 3:03 PM, Benson Margulies <[hidden email]> wrote:
>
> Dependency management cures this; if you don't want to pick up newer
> versions, you can prevent it. Since dep management doesn't know about
> ranges or semantic versioning, you need to then pay attention if you
> want a compatible version that comes along.
>
> I guess it's a question of which poison you prefer. If people here
> prefer bumping artifactids and package names, so be it.
>
>
> On Thu, Jun 2, 2016 at 6:01 PM, Benedikt Ritter <[hidden email]> wrote:
>> Hello Benson,
>>
>> Benson Margulies <[hidden email]> schrieb am Do., 2. Juni 2016 um
>> 23:36 Uhr:
>>
>>> I don't understand what's wrong with semantic versioning and keeping
>>> the same maven coordinates. No sane person should be using RELEASE or
>>> LATEST.
>>>
>>
>> The problem are transitive dependencies. Consider this example:
>>
>> My-Project
>> | -> A -> B -> C 1.2
>> | -> D -> C 2.0
>>
>> In this case my project depends directly on A and D. A depends on B which
>> depends on C in version 1.2. D depends on C in version 2.0. In this case I
>> have no control over the dependencies to C but my project will be broken at
>> run time, because C 1.2 and C 2.0 can not exist at once in the same
>> classpath.
>>
>> Benedikt
>>
>>
>>> ---------------------------------------------------------------------
>>> 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: [ALL] About binary compatibility

Benedikt Ritter-4
In reply to this post by James Carman
James Carman <[hidden email]> schrieb am Fr., 3. Juni 2016 um
00:04 Uhr:

> You've been in karaf land for too long! ;)
>

It's probably a different story when you're working on a framework. It
pretty unlikely to end up with two version of Spring or Hibernate in your
app. But for a library as wildly used as commons-lang it becomes more
likely.


>
> On Thu, Jun 2, 2016 at 5:36 PM Benson Margulies <[hidden email]>
> wrote:
>
> > I don't understand what's wrong with semantic versioning and keeping
> > the same maven coordinates. No sane person should be using RELEASE or
> > LATEST.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [ALL] About binary compatibility

James Carman
I don't think it has anything to do necessarily with framework or not. The
class loading model is just much easier to deal with these situations. As
Benson said, however, there are definitely other issues to contend with.
On Thu, Jun 2, 2016 at 6:14 PM Benedikt Ritter <[hidden email]> wrote:

> James Carman <[hidden email]> schrieb am Fr., 3. Juni 2016 um
> 00:04 Uhr:
>
> > You've been in karaf land for too long! ;)
> >
>
> It's probably a different story when you're working on a framework. It
> pretty unlikely to end up with two version of Spring or Hibernate in your
> app. But for a library as wildly used as commons-lang it becomes more
> likely.
>
>
> >
> > On Thu, Jun 2, 2016 at 5:36 PM Benson Margulies <[hidden email]>
> > wrote:
> >
> > > I don't understand what's wrong with semantic versioning and keeping
> > > the same maven coordinates. No sane person should be using RELEASE or
> > > LATEST.
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [ALL] About binary compatibility

garydgregory
In reply to this post by Ralph Goers
On Thu, Jun 2, 2016 at 3:11 PM, Ralph Goers <[hidden email]>
wrote:

> Dependency management does not cure this if C 1.2 and C 2.0 are not binary
> compatible. Code compiled with the 1.2 version will fail if those methods
> and classes are not in 2.0.
>

Indeed, hence the BC break -> Maven Coord change requirement.

Gary


> Ralph
>
> > On Jun 2, 2016, at 3:03 PM, Benson Margulies <[hidden email]>
> wrote:
> >
> > Dependency management cures this; if you don't want to pick up newer
> > versions, you can prevent it. Since dep management doesn't know about
> > ranges or semantic versioning, you need to then pay attention if you
> > want a compatible version that comes along.
> >
> > I guess it's a question of which poison you prefer. If people here
> > prefer bumping artifactids and package names, so be it.
> >
> >
> > On Thu, Jun 2, 2016 at 6:01 PM, Benedikt Ritter <[hidden email]>
> wrote:
> >> Hello Benson,
> >>
> >> Benson Margulies <[hidden email]> schrieb am Do., 2. Juni 2016
> um
> >> 23:36 Uhr:
> >>
> >>> I don't understand what's wrong with semantic versioning and keeping
> >>> the same maven coordinates. No sane person should be using RELEASE or
> >>> LATEST.
> >>>
> >>
> >> The problem are transitive dependencies. Consider this example:
> >>
> >> My-Project
> >> | -> A -> B -> C 1.2
> >> | -> D -> C 2.0
> >>
> >> In this case my project depends directly on A and D. A depends on B
> which
> >> depends on C in version 1.2. D depends on C in version 2.0. In this
> case I
> >> have no control over the dependencies to C but my project will be
> broken at
> >> run time, because C 1.2 and C 2.0 can not exist at once in the same
> >> classpath.
> >>
> >> Benedikt
> >>
> >>
> >>> ---------------------------------------------------------------------
> >>> 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: [ALL] About binary compatibility

Benson Margulies
Just to cite a fact:

If you write:

<dependencyManagement>
   <dependencies>
      <dependency>
          ...
          <version>x</version>
...

You will get x. Even if transitive dependencies ask for x+10. I only
learned this recently.


On Thu, Jun 2, 2016 at 6:20 PM, Gary Gregory <[hidden email]> wrote:

> On Thu, Jun 2, 2016 at 3:11 PM, Ralph Goers <[hidden email]>
> wrote:
>
>> Dependency management does not cure this if C 1.2 and C 2.0 are not binary
>> compatible. Code compiled with the 1.2 version will fail if those methods
>> and classes are not in 2.0.
>>
>
> Indeed, hence the BC break -> Maven Coord change requirement.
>
> Gary
>
>
>> Ralph
>>
>> > On Jun 2, 2016, at 3:03 PM, Benson Margulies <[hidden email]>
>> wrote:
>> >
>> > Dependency management cures this; if you don't want to pick up newer
>> > versions, you can prevent it. Since dep management doesn't know about
>> > ranges or semantic versioning, you need to then pay attention if you
>> > want a compatible version that comes along.
>> >
>> > I guess it's a question of which poison you prefer. If people here
>> > prefer bumping artifactids and package names, so be it.
>> >
>> >
>> > On Thu, Jun 2, 2016 at 6:01 PM, Benedikt Ritter <[hidden email]>
>> wrote:
>> >> Hello Benson,
>> >>
>> >> Benson Margulies <[hidden email]> schrieb am Do., 2. Juni 2016
>> um
>> >> 23:36 Uhr:
>> >>
>> >>> I don't understand what's wrong with semantic versioning and keeping
>> >>> the same maven coordinates. No sane person should be using RELEASE or
>> >>> LATEST.
>> >>>
>> >>
>> >> The problem are transitive dependencies. Consider this example:
>> >>
>> >> My-Project
>> >> | -> A -> B -> C 1.2
>> >> | -> D -> C 2.0
>> >>
>> >> In this case my project depends directly on A and D. A depends on B
>> which
>> >> depends on C in version 1.2. D depends on C in version 2.0. In this
>> case I
>> >> have no control over the dependencies to C but my project will be
>> broken at
>> >> run time, because C 1.2 and C 2.0 can not exist at once in the same
>> >> classpath.
>> >>
>> >> Benedikt
>> >>
>> >>
>> >>> ---------------------------------------------------------------------
>> >>> 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: [ALL] About binary compatibility

Emmanuel Bourg-3
In reply to this post by garydgregory
Le 3/06/2016 à 00:09, Gary Gregory a écrit :

> -1
>
> Timing is irrelevant. You cannot control what will end up in an app stack.
> Once released, that's it unfortunately, otherwise, the door to jar hell is
> open.

Timing is relevant because the probability of jar hell increases with
time. If the version has been in use for 1 year there are more chances
that the API you'd like to break has been used somewhere than with a
version released only one week ago. And if someone complains we can
still revert the change and release foo 1.3.2.

I would call this "optimistic compatibility breakage", we should be able
to assess if the change is likely to cause issues in sensible use cases,
and if we make a mistake, just revert it.

Emmanuel Bourg


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

123