[ALL] About binary compatibility

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

Re: [ALL] About binary compatibility

Benedikt Ritter-4
Benson Margulies <[hidden email]> schrieb am Fr., 3. Juni 2016 um
00:43 Uhr:

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

Yes thats true. Coming back to our example you could specify:

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

Maven will use the dependency which is closest to the project root. So in
the first example C 2.0 was closed. Now we have defined a direct dependency
to C 1.2. maven will use this one instead.

But what do you win by this? Your app is still broken. This is a problem
you can't resolve in your pom. This is the reason we're changing maven and
package coords so you can have both versions.

Benedikt


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

Matt Benson-2
In reply to this post by Benedikt Ritter-4
On Thu, Jun 2, 2016 at 3: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.
> - 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 to all points

Matt


> Benedikt
>
Reply | Threaded
Open this post in threaded view
|

Re: [ALL] About binary compatibility

Jörg Schaible-5
In reply to this post by Benson Margulies
Hi Benson,

Benson Margulies wrote:

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

Yes, but you dropped the significant part here: groupId/artifactId. Your
example applies only if G:A is unchanged. Therefore we change G:A - and in
consequence also the package name, because you may end up now with both jars
in the classpath.

- 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

sebb-2-2
In reply to this post by Benedikt Ritter-4
On 2 June 2016 at 21:42, 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, with the proviso that we must not break BC in the *public* API.
Unfortunately it is not always clear what is public.

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

I don't see why being a volunteer makes breaking BC more acceptable.
Remember that many of the consumers of the components will also be
volunteers (not least in other ASF projects) who will have to deal
with the consequences.

We should remember that there are generally many more consumers of the
components than there are developers.
So a small change is multiplied by a large number of people who need
to do the work.

If BC can be maintained by a developer spending a bit more time on the
code, that seems to me to be a worthy goal.

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

Versioning is largely separate from BC.

But again, Java upgrades can affect downstream consumers, so care must
be taken not to exclude too many potential users.

> What is your view on the topic?

Note that the above concerns depend to some extent on which component
is involved.
The lower-level components and popular dependencies (LANG, IO, NET
etc) need to be more careful about breaking changes.
Components such as MATH and IMAGING are less likely to be deep in a
dependency chain, so API/Java changes will likely affect fewer
consumers.

> 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

Gilles Sadowski
In reply to this post by Benedikt Ritter-4
On Thu, 02 Jun 2016 21:35:45 +0000, Benedikt Ritter wrote:

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

[For the release process.]
I suggest people examine this document (in the "develop" branch of the
"math" repository):
   doc/release/release.howto.txt

Regards,
Gilles

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


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

jochen-2
In reply to this post by Benson Margulies
On Thu, Jun 2, 2016 at 11: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.

The real problem is, IMO, not the versioning scheme, but the fact,
that most application servers, etc. are shipping a lot of commons
stuff.
Or, in other words: You rarely know precisely, which version of
commons Foo you are going to use. Or, to put it different: "Jar hell".



--
The next time you hear: "Don't reinvent the wheel!"

http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg

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

Oliver Heger-3
In reply to this post by Benedikt Ritter-4
Hi Benedikt,

Am 02.06.2016 um 22:42 schrieb Benedikt Ritter:

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

these points are rather technical ones, and most of us will probably
agree. The more important question is IMHO: when do we explicitly break
BC because we want to make use of new language features or switch to a
different design? In this area we used to be very conservative.

Take BCEL as an example. There was a strong momentum about half a year
or so ago to push out a new major release breaking BC. Then discussion
started to revert breaking changes. This would of course have been the
ideal solution for all users: getting a new version without migration
effort. However, the result was that work on reverting changes started,
but was never finished. The momentum vanished, and the release is still
overdue. So would it has been better to break BC in this case? I tend to
say yes.

Or let's discuss another component: [lang]. The last major release
happened about 5 years ago. In software business these are ages. So
would it make sense to start working on a new version focusing on Java 8
and better support for Lambdas? We could at least start something in an
experimental branch or the sandbox to experiment with new functionality.
But it is obviously not our style to do this.

It is certainly difficult to find the right balance between stability
and innovation. For our fundamental components it is for sure no good
idea to push out an incompatible major release every few months. But
every 3 or 4 years when there are significant changes in the Java
ecosystem would probably be okay.

My $0.02
Oliver

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

Benedikt Ritter-4
Hello Oilver,

Oliver Heger <[hidden email]> schrieb am So., 5. Juni 2016 um
16:46 Uhr:

> Hi Benedikt,
>
> Am 02.06.2016 um 22:42 schrieb Benedikt Ritter:
> > 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?
>
> these points are rather technical ones, and most of us will probably
> agree. The more important question is IMHO: when do we explicitly break
> BC because we want to make use of new language features or switch to a
> different design? In this area we used to be very conservative.
>

Nevertheless I think we should document this. I'm tired of "why can't we
implement this in a Java 6 compatible way" arguments. Java 6 is dead and
Java 7 soon will be. There is no reason for us to support Java versions
which not even Oracle supports anymore.


>
> Take BCEL as an example. There was a strong momentum about half a year
> or so ago to push out a new major release breaking BC. Then discussion
> started to revert breaking changes. This would of course have been the
> ideal solution for all users: getting a new version without migration
> effort. However, the result was that work on reverting changes started,
> but was never finished. The momentum vanished, and the release is still
> overdue. So would it has been better to break BC in this case? I tend to
> say yes.
>

I agree with you on this.


>
> Or let's discuss another component: [lang]. The last major release
> happened about 5 years ago. In software business these are ages. So
> would it make sense to start working on a new version focusing on Java 8
> and better support for Lambdas? We could at least start something in an
> experimental branch or the sandbox to experiment with new functionality.
> But it is obviously not our style to do this.
>

We have done this in the past for BeanUtils2 in the sandbox. I don't think
experiments should be forked into the sandbox. My feeling is, that those
experiments get less attention.

Speaking about [lang]: I discussed a redesign with Henri a year ago. The
only problem I see is the time constraint. [lang] is a pretty large code
base (~29k LoC) and I fear the that I won't be able the bring the redesign
to an end. If others like to push that, I'm all for that.


>
> It is certainly difficult to find the right balance between stability
> and innovation. For our fundamental components it is for sure no good
> idea to push out an incompatible major release every few months. But
> every 3 or 4 years when there are significant changes in the Java
> ecosystem would probably be okay.
>

Again I agree.

Thank you,
Benedikt


>
> My $0.02
> Oliver
>
> >
> > 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

sebb-2-2
In the case of BCEL, the coding actually stalled on fixing some bugs
which were proving both difficult to test and fix.

The code that was reverted to become BC was largely orthogonal to that.



On 5 June 2016 at 16:58, Benedikt Ritter <[hidden email]> wrote:

> Hello Oilver,
>
> Oliver Heger <[hidden email]> schrieb am So., 5. Juni 2016 um
> 16:46 Uhr:
>
>> Hi Benedikt,
>>
>> Am 02.06.2016 um 22:42 schrieb Benedikt Ritter:
>> > 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?
>>
>> these points are rather technical ones, and most of us will probably
>> agree. The more important question is IMHO: when do we explicitly break
>> BC because we want to make use of new language features or switch to a
>> different design? In this area we used to be very conservative.
>>
>
> Nevertheless I think we should document this. I'm tired of "why can't we
> implement this in a Java 6 compatible way" arguments. Java 6 is dead and
> Java 7 soon will be. There is no reason for us to support Java versions
> which not even Oracle supports anymore.
>
>
>>
>> Take BCEL as an example. There was a strong momentum about half a year
>> or so ago to push out a new major release breaking BC. Then discussion
>> started to revert breaking changes. This would of course have been the
>> ideal solution for all users: getting a new version without migration
>> effort. However, the result was that work on reverting changes started,
>> but was never finished. The momentum vanished, and the release is still
>> overdue. So would it has been better to break BC in this case? I tend to
>> say yes.
>>
>
> I agree with you on this.
>
>
>>
>> Or let's discuss another component: [lang]. The last major release
>> happened about 5 years ago. In software business these are ages. So
>> would it make sense to start working on a new version focusing on Java 8
>> and better support for Lambdas? We could at least start something in an
>> experimental branch or the sandbox to experiment with new functionality.
>> But it is obviously not our style to do this.
>>
>
> We have done this in the past for BeanUtils2 in the sandbox. I don't think
> experiments should be forked into the sandbox. My feeling is, that those
> experiments get less attention.
>
> Speaking about [lang]: I discussed a redesign with Henri a year ago. The
> only problem I see is the time constraint. [lang] is a pretty large code
> base (~29k LoC) and I fear the that I won't be able the bring the redesign
> to an end. If others like to push that, I'm all for that.
>
>
>>
>> It is certainly difficult to find the right balance between stability
>> and innovation. For our fundamental components it is for sure no good
>> idea to push out an incompatible major release every few months. But
>> every 3 or 4 years when there are significant changes in the Java
>> ecosystem would probably be okay.
>>
>
> Again I agree.
>
> Thank you,
> Benedikt
>
>
>>
>> My $0.02
>> Oliver
>>
>> >
>> > 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

Thomas Vandahl
In reply to this post by sebb-2-2
On 03.06.16 10:38, sebb wrote:
> On 2 June 2016 at 21:42, Benedikt Ritter <[hidden email]> wrote:
>> - 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, with the proviso that we must not break BC in the *public* API.
> Unfortunately it is not always clear what is public.
>

All commons components are released with OSGi bundle metadata, where the
packages for a public API can be stated. If this information is
maintained correctly, everyone should be able to tell public from
private API changes.

Bye, Thomas.



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

sebb-2-2
On 5 June 2016 at 18:51, Thomas Vandahl <[hidden email]> wrote:

> On 03.06.16 10:38, sebb wrote:
>> On 2 June 2016 at 21:42, Benedikt Ritter <[hidden email]> wrote:
>>> - 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, with the proviso that we must not break BC in the *public* API.
>> Unfortunately it is not always clear what is public.
>>
>
> All commons components are released with OSGi bundle metadata, where the
> packages for a public API can be stated. If this information is
> maintained correctly, everyone should be able to tell public from
> private API changes.

The problem is determining what is supposed to be public, not documenting it.

Though I would question whether non-OSGi users would think to look at
the metadata.

> Bye, Thomas.
>
>
>
> ---------------------------------------------------------------------
> 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
On Jun 5, 2016 11:12 AM, "sebb" <[hidden email]> wrote:
>
> On 5 June 2016 at 18:51, Thomas Vandahl <[hidden email]> wrote:
> > On 03.06.16 10:38, sebb wrote:
> >> On 2 June 2016 at 21:42, Benedikt Ritter <[hidden email]> wrote:
> >>> - 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, with the proviso that we must not break BC in the *public* API.
> >> Unfortunately it is not always clear what is public.
> >>
> >
> > All commons components are released with OSGi bundle metadata, where the
> > packages for a public API can be stated. If this information is
> > maintained correctly, everyone should be able to tell public from
> > private API changes.
>
> The problem is determining what is supposed to be public, not documenting
it.

We could document OSGi as how we spec public APIs.

Gary

>
> Though I would question whether non-OSGi users would think to look at
> the metadata.
>
> > Bye, Thomas.
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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
Not quite. OSGi is a special case. It's much more restrictive than simple
J2SE, because it can be. In the general case, the public API for OSGi is
different from the public API for J2SE. Let's not confuse the two.

On Sun, Jun 5, 2016 at 2:30 PM Gary Gregory <[hidden email]> wrote:

> On Jun 5, 2016 11:12 AM, "sebb" <[hidden email]> wrote:
> >
> > On 5 June 2016 at 18:51, Thomas Vandahl <[hidden email]> wrote:
> > > On 03.06.16 10:38, sebb wrote:
> > >> On 2 June 2016 at 21:42, Benedikt Ritter <[hidden email]> wrote:
> > >>> - 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, with the proviso that we must not break BC in the *public* API.
> > >> Unfortunately it is not always clear what is public.
> > >>
> > >
> > > All commons components are released with OSGi bundle metadata, where
> the
> > > packages for a public API can be stated. If this information is
> > > maintained correctly, everyone should be able to tell public from
> > > private API changes.
> >
> > The problem is determining what is supposed to be public, not documenting
> it.
>
> We could document OSGi as how we spec public APIs.
>
> Gary
>
> >
> > Though I would question whether non-OSGi users would think to look at
> > the metadata.
> >
> > > Bye, Thomas.
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > 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

jochen-2
In reply to this post by Oliver Heger-3
On Sun, Jun 5, 2016 at 4:46 PM, Oliver Heger
<[hidden email]> wrote:

> Take BCEL as an example. There was a strong momentum about half a year
> or so ago to push out a new major release breaking BC. Then discussion
> started to revert breaking changes. This would of course have been the
> ideal solution for all users: getting a new version without migration
> effort. However, the result was that work on reverting changes started,
> but was never finished. The momentum vanished, and the release is still
> overdue. So would it has been better to break BC in this case? I tend to
> say yes.

I don't think that example is very helpful. At least, I don't know how
anyone should have foreseen the outcome.

> Or let's discuss another component: [lang]. The last major release
> happened about 5 years ago. In software business these are ages. So
> would it make sense to start working on a new version focusing on Java 8
> and better support for Lambdas? We could at least start something in an
> experimental branch or the sandbox to experiment with new functionality.
> But it is obviously not our style to do this.

In that case, i'd strongly be in favour of a new release branch (no
need for sandbox) with all the incompatible changes, and a release out
of that branch. As long, as the old branch remains available for minor
maintenance issues.

Jochen

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

Ralph Goers
In reply to this post by Oliver Heger-3
I think we should adopt Java 9’s multi-release jars [1] as standard practice.  While this won’t let us update our APIs without breaking compatibility (which may still be necessary), it will allow us to leverage some features in newer versions of Java without worrying about breaking backward compatibility.  

I also see no reason we can’t leave links on the web site to the last release that supported an older version of Java and have a branch for further work if anyone wants to do it.  

In the end I think we have to have an approach where we can move forward and support the newer versions of Java more quickly while still continuing to be able to support older versions - if we choose to.

As far as moving forward and breaking binary compatibility, I believe Oliver did a great job with Configuration 2.0.  He first worked on an experimental branch and got it to the state where he could release it.  Although I wish I could have contributed more to his efforts I think the way he went about it encouraged others to review what he was doing and participate if and when they wanted to.  At the same time bugs in the older releases continued to be addressed.

Ralph

[1] http://openjdk.java.net/jeps/238 <http://openjdk.java.net/jeps/238>

> On Jun 5, 2016, at 7:46 AM, Oliver Heger <[hidden email]> wrote:
>
> Hi Benedikt,
>
> Am 02.06.2016 um 22:42 schrieb Benedikt Ritter:
>> 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?
>
> these points are rather technical ones, and most of us will probably
> agree. The more important question is IMHO: when do we explicitly break
> BC because we want to make use of new language features or switch to a
> different design? In this area we used to be very conservative.
>
> Take BCEL as an example. There was a strong momentum about half a year
> or so ago to push out a new major release breaking BC. Then discussion
> started to revert breaking changes. This would of course have been the
> ideal solution for all users: getting a new version without migration
> effort. However, the result was that work on reverting changes started,
> but was never finished. The momentum vanished, and the release is still
> overdue. So would it has been better to break BC in this case? I tend to
> say yes.
>
> Or let's discuss another component: [lang]. The last major release
> happened about 5 years ago. In software business these are ages. So
> would it make sense to start working on a new version focusing on Java 8
> and better support for Lambdas? We could at least start something in an
> experimental branch or the sandbox to experiment with new functionality.
> But it is obviously not our style to do this.
>
> It is certainly difficult to find the right balance between stability
> and innovation. For our fundamental components it is for sure no good
> idea to push out an incompatible major release every few months. But
> every 3 or 4 years when there are significant changes in the Java
> ecosystem would probably be okay.
>
> My $0.02
> Oliver
>
>>
>> Benedikt
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

Reply | Threaded
Open this post in threaded view
|

Fwd: [ALL] About binary compatibility

jochen-2
---------- Forwarded message ----------
From: Ralph Goers <[hidden email]>
Date: Mon, Jun 6, 2016 at 1:11 AM
Subject: Re: [ALL] About binary compatibility
To: Commons Developers List <[hidden email]>


I think we should adopt Java 9’s multi-release jars [1] as standard
practice.  While this won’t let us update our APIs without breaking
compatibility (which may still be necessary), it will allow us to
leverage some features in newer versions of Java without worrying
about breaking backward compatibility.

Strong disagreement. Java 9 is not even out, and I heard noone express
any desire to *use* these beasts. In other words: We'd serve a
non-existing demand. That can't help anyone,
in particular not ourselves.

Jochen

--
The next time you hear: "Don't reinvent the wheel!"

http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg

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

Ralph Goers

> On Jun 6, 2016, at 11:11 AM, Jochen Wiedmann <[hidden email]> wrote:
>
> ---------- Forwarded message ----------
> From: Ralph Goers <[hidden email]>
> Date: Mon, Jun 6, 2016 at 1:11 AM
> Subject: Re: [ALL] About binary compatibility
> To: Commons Developers List <[hidden email]>
>
>
> I think we should adopt Java 9’s multi-release jars [1] as standard
> practice.  While this won’t let us update our APIs without breaking
> compatibility (which may still be necessary), it will allow us to
> leverage some features in newer versions of Java without worrying
> about breaking backward compatibility.
>
> Strong disagreement. Java 9 is not even out, and I heard noone express
> any desire to *use* these beasts. In other words: We'd serve a
> non-existing demand. That can't help anyone,
> in particular not ourselves.

I am not sure what “beasts” you are talking about, and the tone of your comment makes me wonder if you were saying the same thing about Lamda’s and Streams before Java 8 was released. Just because Java 9 hasn’t been released doesn’t mean you shouldn’t be aware of what it will offer and how you might take advantage of those features.

All the multi-release support does is let you have a version of a class targeted at Java 9 as well as a class targeted at a previous version in the same jar. The user will get the version of the class that is appropriate for their runtime. The idea behind this is that you can start to take advantage of features in newer versions of the JDK without having to force the whole library(and your users) to upgrade.  This allows things like being able to leverage the java.time stuff event though you still support Java 7.

Ralph




---------------------------------------------------------------------
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 jochen-2
On Mon, Jun 6, 2016 at 11:11 AM, Jochen Wiedmann <[hidden email]>
wrote:

> ---------- Forwarded message ----------
> From: Ralph Goers <[hidden email]>
> Date: Mon, Jun 6, 2016 at 1:11 AM
> Subject: Re: [ALL] About binary compatibility
> To: Commons Developers List <[hidden email]>
>
>
> I think we should adopt Java 9’s multi-release jars [1] as standard
> practice.  While this won’t let us update our APIs without breaking
> compatibility (which may still be necessary), it will allow us to
> leverage some features in newer versions of Java without worrying
> about breaking backward compatibility.
>
> Strong disagreement. Java 9 is not even out, and I heard noone express
> any desire to *use* these beasts. In other words: We'd serve a
> non-existing demand. That can't help anyone,
> in particular not ourselves.
>

Yeah, it seems a little early to jump on that bandwagon.

I'd rather keep a mainline of development of new releases on a recent JRE
like Java 7 or 8 and let people who really want older JREs maintain
branches.

Gary

>
> Jochen
>
> --
> The next time you hear: "Don't reinvent the wheel!"
>
>
> http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg
>
> ---------------------------------------------------------------------
> 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

> On Jun 6, 2016, at 11:38 AM, Gary Gregory <[hidden email]> wrote:
>
> On Mon, Jun 6, 2016 at 11:11 AM, Jochen Wiedmann <[hidden email] <mailto:[hidden email]>>
> wrote:
>
>> ---------- Forwarded message ----------
>> From: Ralph Goers <[hidden email]>
>> Date: Mon, Jun 6, 2016 at 1:11 AM
>> Subject: Re: [ALL] About binary compatibility
>> To: Commons Developers List <[hidden email]>
>>
>>
>> I think we should adopt Java 9’s multi-release jars [1] as standard
>> practice.  While this won’t let us update our APIs without breaking
>> compatibility (which may still be necessary), it will allow us to
>> leverage some features in newer versions of Java without worrying
>> about breaking backward compatibility.
>>
>> Strong disagreement. Java 9 is not even out, and I heard noone express
>> any desire to *use* these beasts. In other words: We'd serve a
>> non-existing demand. That can't help anyone,
>> in particular not ourselves.
>>
>
> Yeah, it seems a little early to jump on that bandwagon.
>
> I'd rather keep a mainline of development of new releases on a recent JRE
> like Java 7 or 8 and let people who really want older JREs maintain
> branches.
>

Gary, your response seems at odds with what I am saying. I’m not talking about supporting Java 6.  What I am suggesting is that this feature in Java 9 will let you take advantage of features in Java 8 or 9 while still being able to have the same jar run in Java 7.  In other words your can have a project where the Maven is told the target runtime is Java 7 but can take advantage of features in Java 8 or 9.  You don’t have to delay taking advantage of features just because you aren’t ready to abandon your Java 7 (or 8 when that is relevant) users.

Ralph

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] About binary compatibility

James Carman
In reply to this post by Ralph Goers
On Sun, Jun 5, 2016 at 7:12 PM Ralph Goers <[hidden email]>
wrote:

> I think we should adopt Java 9’s multi-release jars [1] as standard
> practice.  While this won’t let us update our APIs without breaking
> compatibility (which may still be necessary), it will allow us to leverage
> some features in newer versions of Java without worrying about breaking
> backward compatibility.
>
>
When do you propose we adopt this new feature?  As of now, the issue is
still listed as "Unresolved" in their issue tracking:

https://bugs.openjdk.java.net/browse/JDK-8047305

I'm not saying I'm against the idea (on the surface it sounds pretty
interesting).  I'm just saying that it doesn't appear to be an option for
us at present.  We could definitely be one of the early-adopters of this
new feature (one a few select components first) and show folks how it's
done, once it is available.  Common Lang seems like a likely candidate for
such a feature.
123