|Re: [jgit-dev] About package versioning|
I'm late to the party, but... about change https://git.eclipse.org/r/#/c/
"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.
jgit-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
Back to the top