[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jgit-dev] [egit-dev] Breaking the Tag API (was release 1.2 ahead)
|
One more followup question on this discussion:
Is removing/renaming a String from JGitText considered a breaking API change?
Kevin
On Thu, Dec 15, 2011 at 11:38 PM, Matthias Sohn
<matthias.sohn@xxxxxxxxxxxxxx> wrote:
2011/12/15 Tomasz Zarna
<tzarna@xxxxxxxxx>
On Sun, Dec 11, 2011 at 20:45, Robin Rosenberg
<robin.rosenberg@xxxxxxxxxx> wrote:
> Robin Rosenberg skrev 2011-12-03 12.12:
>>
>> Matthias Sohn skrev 2011-12-03 01.20:
>>>
>>> 2011/12/2 Robin Rosenberg <robin.rosenberg@xxxxxxxxxx
>>> <mailto:robin.rosenberg@xxxxxxxxxx>>
>>
>> [...]
>>>
>>>
>>> Here is an API bug.
>>>
>>> https://bugs.eclipse.org/bugs/__show_bug.cgi?id=360650
>>> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=360650>
>>>
>>> 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:
>>
>> http://egit.eclipse.org/r/#change,4726
>
>
> 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 of
compatibility in a later step I added API checking to the JGit build
using the maven-clirr-plugin. So the hudson build is now generating
an API compatility report, find it under the path target/site/clirr-report.html
relative to the respective module, for the main jgit library bundle in
the nightly build it is located here:
I didn't yet find a way to publish that in the hudson UI so that it can be
seen from the JGit build job's home page.
--
Matthias
_______________________________________________
egit-dev mailing list
egit-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/egit-dev
