Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jgit-dev] Breaking the Tag API (was[egit-dev] release 1.2 ahead)

Do we want to remove the breaking changes (that I made) to CloneCommand, FetchCommand, and PushCommand in stable-1.2?

It is trivial to add them back and just call super.

Kevin

On Fri, Dec 16, 2011 at 4:38 AM, Matthias Sohn <matthias.sohn@xxxxxxxxxxxxxx> wrote:
2011/12/16 Tomasz Zarna <tzarna@xxxxxxxxx>
On Fri, Dec 16, 2011 at 08:38, 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:
> https://hudson.eclipse.org/hudson/job/jgit/ws/org.eclipse.jgit/target/site/clirr-report.html
>
> 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.

That's definitely a step in the right direction, but you can catch
some of those errors earlier by setting up API Tooling[1].

yes I know, but I want this to be also enforced in the central build
so that we also catch API changes coming from developers which
don't use API tooling in Eclipse. I didn't yet find a way to use
the API tooling from Maven hence I came up with the solution
using the maven-clirr-plugin.
 
Also note that these tools won't help you with cases like in bug
366818 [2], where Orion broke because one exception in JGit got
replaced with another:
org.eclipse.jgit.errors.CheckoutConflictException >
org.eclipse.jgit.api.errors.CheckoutConflictException [3].

Don't get me wrong guys, you're doing great job. I'm just trying to
make my life easier as a JGit API consumer.

 that's in our interest as well

--
Matthias


Back to the top