Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jgit-dev] About package versioning

Agreed, we should not make breaking changes to the public API of overrideable (public, non-final, non-internal) classes in minor releases for this reason.

IMHO, however, we are making too much of the merge package public. The *Merger implementations feel to me like they belong in an internal package, which means consumers are free to sublcass them, but can expect breaking API changes. In my ideal world, ThreeWayMerger would be in the public org.eclipse.jgit.merge package, and there would be a separate org.eclipse.jgit.merge.internal package where the implementations live.

Of course, that ship has sailed, so I'm just grumbling.

On Mon, Oct 9, 2017 at 9:58 AM, Laurent Goubet <laurent.goubet@xxxxxxx> wrote:

I'm late to the party, but... about change

"This breaks only implementors, so people who are subclassing our methods. But clients who are just using our public API should not be broken in a minor release."

API versioning isn't _only_ for callers. Your implementors also depend on the version of your packages to properly specify which versions of your API they are compatible with. We expect that there will be no API breakages in minor versions.

In EMF Compare, we are depending on "JGit [4.0, 5.0)" (Okay, we did have an issue that we depend on "anything higher than 4.0" without specifying the max) => we expect that the API we're using or implementing won't break in minor releases, but we know a major release can break us.

This particular change broke us, since we do extend the ResolveMerger, and we do use the processEntry method (note that we don't even override it, but even calling it broke since you changed the signature). Mathieu's initial implementation was the right way to do it: duplicate the method, one of which being deprecated so that implementors are not broken, but know they have an action to take on that call to switch to the newer API.

As it stands, EMF Compare's build broke, and I'm forced to change EMF Compare's range of versions to depend on JGit 4.9 minimum, which means older versions of EMF Compare will simply break if clients update jgit because we won't rebuild with a more restrictive version range.

Please remember you might have implementors other than EGit.



Laurent Goubet
+33 2 51 13 51 42

7 Boulevard Ampère - Carquefou - France | twitter | linkedin

jgit-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Back to the top