This is still accessible through cache.getAdvancedCache().getRpcManager(), so it still counts as public API. I doubt that any user is using that method directly, but OTOH it's public so who knows. What do people think? Shall we be strict with regard to such 'obscure' methods between minor releases?

> As you see, IMHO such API changes do not have much effect in normal > situations. I can imagine only problems, when the changed methods are > used within dist exec calls and there are (during update or whatever) > different versions of infinispan inside the cluster. Does this really happen? I'm asking purely out of ignorance but on instinct I think that running different versions on the cluster is probably a bit risky?

Hi guys, is this topic related? https://community.jboss.org/wiki/RollingUpgradesInInfinispan

I'd assume that *whole* cluster will be upgraded to some higher version. Running cluster with different versions seems risky to me too. This ^^ process should be smooth but I don't know how about changes in API. I'm very interested in this topic - that's the reason why I jumped in to your discussion.

Thank you! ----- Original Message ----- From: "Thomas Fromm" <tf(a)tfromm.com&gt; To: "infinispan -Dev List" <infinispan-dev(a)lists.jboss.org&gt; Sent: Thursday, November 22, 2012 8:23:22 AM Subject: Re: [infinispan-dev] public API/what should be preserve between minor releases? On 22.11.2012 04:11, Navin Surtani wrote: >> As you see, IMHO such API changes do not have much effect in normal >> situations. I can imagine only problems, when the changed methods are >> used within dist exec calls and there are (during update or whatever) >> different versions of infinispan inside the cluster. > Does this really happen? I'm asking purely out of ignorance but on instinct I think that running different versions on the cluster is probably a bit risky? Thats the plan for our own software. Customer can update the nodes one by one, of course only for patch releases. I'd expect (or at least hope) that this will be also possible with infinispan in case of critical bug was fixed or smth. _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

On 21 Nov 2012, at 17:02, Mircea Markus <mmarkus(a)redhat.com&gt; wrote: > Hi, > > Cache, CacheManager and all the API that's in the org.infinispan package needs to be backward compatible. > > What about more obscure stuff, e.g. > RpcManager.invokeRemotelyInFuture(Collection<Address> recipients, ReplicableCommand rpc, boolean usePriorityQueue, NotifyingNotifiableFuture<Object> future); > > This is still accessible through cache.getAdvancedCache().getRpcManager(), so it still counts as public API. I doubt that any user is using that method directly, but OTOH it's public so who knows. > What do people think? Shall we be strict with regard to such 'obscure' methods between minor releases? More than something exposed via AdvancedCache, it's more of a concern when it comes to people writing custom interceptors and may have direct access to the RpcManager. What do you intend to change in the RpcManager?