|Re: [jgit-dev] [egit-dev] Breaking the Tag API (was release 1.2 ahead)|
2011/12/15 Tomasz Zarna <tzarna@xxxxxxxxx>
On Sun, Dec 11, 2011 at 20:45, Robin Rosenberg
> Robin Rosenberg skrev 2011-12-03 12.12:
>> Matthias Sohn skrev 2011-12-03 01.20:
>>> 2011/12/2 Robin Rosenberg <robin.rosenberg@xxxxxxxxxx
>>> Here is an API bug.
>>> That's easy to fix if we don't consider that fixing it would
>>> involve breaking the API. Would that be ok? The API iself is part of
>>> the bug here.
>>> I think we should fix this as currently this is a broken API
>> Breaking and fixing API here:
> We have some disagreement about this one. My opinion is that
> we should not introduce a new object for tags, but rather treat
> them as branches for which we do not have special objects either.
> Both can and should be handled as Ref objects.
> If we cannot agree, then we'd have to break the API post-1.2 and
> since breaking API's are a bad thing and 2.0 is not on the horizon
> we should break it as soon as possible.
> An alternative to breaking the API would be to introduce a new API.
> Name: TagCommand2? That would follow the pattern used elsewhere when
> it has been found out that an API is not sufficient.
> In any case we'd have to agree on the return type.
>> http://egit.eclipse.org/r/#change,4727 (demo)
I'd go with the former i.e. break the API as it has already happened
many times in 1.x and no one paid much attention to it. The API
Tooling reports almost 100 errors for org.eclipse.jgit when run
against 3.7.1 baseline. An example: CloneCommand has lost its
setTimeout(int) and setCredentialsProvider(CredentialsProvider)
methods added by Stefan in April (not sure about the version). They
are now inherited from TransportCommand but it has been changed in the
meantime.In order to make this more transparent and to enable enforcement ofcompatibility in a later step I added API checking to the JGit buildusing the maven-clirr-plugin. So the hudson build is now generatingan API compatility report, find it under the path target/site/clirr-report.htmlrelative to the respective module, for the main jgit library bundle inthe nightly build it is located here:I didn't yet find a way to publish that in the hudson UI so that it can beseen from the JGit build job's home page.--
egit-dev mailing list
Back to the top