Well, obviously a tool can only go so far ... I sure hope nobody has the hope
that tools can solve this problem. Once they can, we're out of work :-)
This kind of changes are the main reason to place the packageinfo in the same
directory as where the change is made. Desperately hoping to be updated.
Interestingly, your change as described could be fully compatible, neither
description excludes the other :-)
Kind regards,
Peter Kriens
On 14 apr. 2013, at 01:09, Marcel Offermans wrote:
> On Apr 14, 2013, at 0:13 AM, Ferry Huberts <[email protected]> wrote:
>> On 13/04/13 23:56, Emily Jiang wrote:
>>> I still disagree. As I mentioned in the call, most interfaces will be
>>> provider type (implemented by service provider). If we assume them all
>>> to be consumer type (listener pattern), we will bump the major version
>>> unnecessarily when a new method is added. Our guess will be wrong 99% or
>>> even more. I would like to hear what majority people think.
>>
>> As BJ said, @ConsumerType is the _safe_ guess.
>
> And even that guess is not really safe. I always use the following example to
> explain. If you have an interface A:
>
> /* version 1.0 */
> interface A {
> /* returns true in a certain condition */
> boolean check();
> }
>
> And in a new version, this interface has been changed like this:
>
> /* version ??? */
> interface A {
> /* returns false in a certain condition */
> boolean check();
> }
>
> Then, even though the method signature has not changed in any way, the
> semantics of this interface have changed in an incompatible way and a major
> bump in versioning is required. There is just no way tools are going to pick
> up on this as long as they're just based on Java (byte)code, you actually
> need to understand the documentation to understand this. So this is another
> instance where you might be in for some unpleasant surprises if you blindly
> use the output of such versioning tools.
>
> Greetings, Marcel
>
>
>
> _______________________________________________
> OSGi Developer Mail List
> [email protected]
> https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
