Thanks Alex.
It was not marked as NoImplement. It's backwardly incompatible
and so a major version increment is required.
There are certainly some clients implementing, but my intention
with asking was to find out how many it might affect.
Scott
On 2/7/2013 12:18 AM, Alex Blewitt wrote:
It depends if this was marked as @NoImplement or not.
If it was, adding a new method is backward compatible and
should be fine, with a bump to the minor version.
If it wasn't, it's backwardly incompatible and so the change
should occur with a bump to the major version.
The I*2 pattern is a way of introducing new methods to
interfaces without bumping the major version.
If its unlikely there are clients implementing this then
fixing the API makes sense - but remember to bump the major
version to signify a backward incompatible change.
Alex
Sent from my iPhone 5
On 2/6/2013 4:38 PM, Wim Jongman
wrote:
Hi Scott,
Would it not be better to deprecate the method and
introduce a new interface?
IRemoteResponseDeserializer2
Best
regards,
Wim
I suppose it depends upon what you mean by better. Since
this is an API mistake, I would say it would be better to just
fix it...and not have multiple ways of doing the same thing
(along with the confusion that comes...e.g. 'which
IRemoteResponseDeserializer do I use?'). OTOH, if lots of
clients would be broken...causing many difficult fixes, then
definitely 'better' would be not breaking things...and
allowing the old interface to remain.
That's why I'm trying to get a feel for how much pain this
would cause among consumers. If it's not a lot of pain,
better would be to fix it, if it is a lot of pain, then better
to do something else.
Scott
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev
