[infinispan-dev] API stability policy for major vs minor vs patch releases

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

[infinispan-dev] API stability policy for major vs minor vs patch releases

Paul Ferraro
In my course of upgrading AS6 from 4.2.0.Final to 4.2.1.CR3, I came
across a NoSuchMethodError.  Specifically, a couple AS components
utilize DistributionManager.isLocal(String), which was dropped from the
public API sometime after 4.2.1.CR1.

While the fix is trivial enough (in the end I'll need to perform several
component release to compensate), this raises the larger issue of a API
stability policy for major vs minor vs patch releases.  At the very
least, I don't think its wise to remove methods from a public interface
in a patch release.  In my opinion, removing methods from a public API
should only happen across major releases, and even then, only after
being formally deprecated.

Thoughts?

Paul

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] API stability policy for major vs minor vs patch releases

Bela Ban
+1000. Although I can't claim I've never (unknowingly) violated this
principle...

On 2/23/11 6:00 PM, Paul Ferraro wrote:

> In my course of upgrading AS6 from 4.2.0.Final to 4.2.1.CR3, I came
> across a NoSuchMethodError.  Specifically, a couple AS components
> utilize DistributionManager.isLocal(String), which was dropped from the
> public API sometime after 4.2.1.CR1.
>
> While the fix is trivial enough (in the end I'll need to perform several
> component release to compensate), this raises the larger issue of a API
> stability policy for major vs minor vs patch releases.  At the very
> least, I don't think its wise to remove methods from a public interface
> in a patch release.  In my opinion, removing methods from a public API
> should only happen across major releases, and even then, only after
> being formally deprecated.


--
Bela Ban
Lead JGroups / Clustering Team
JBoss
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] API stability policy for major vs minor vs patch releases

Erik Salter
In reply to this post by Paul Ferraro
+1.5B

This method is a core component of my local transaction/redirection implementation.  Hopefully, this was an oversight and not intended to be removed.

Erik

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Paul Ferraro
Sent: Wednesday, February 23, 2011 12:01 PM
To: [hidden email]
Subject: [infinispan-dev] API stability policy for major vs minor vs patch releases

In my course of upgrading AS6 from 4.2.0.Final to 4.2.1.CR3, I came across a NoSuchMethodError.  Specifically, a couple AS components utilize DistributionManager.isLocal(String), which was dropped from the public API sometime after 4.2.1.CR1.

While the fix is trivial enough (in the end I'll need to perform several component release to compensate), this raises the larger issue of a API stability policy for major vs minor vs patch releases.  At the very least, I don't think its wise to remove methods from a public interface in a patch release.  In my opinion, removing methods from a public API should only happen across major releases, and even then, only after being formally deprecated.

Thoughts?

Paul

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev

The information contained in this message is legally privileged and confidential, and is intended for the individual or entity to whom it is addressed (or their designee). If this message is read by anyone other than the intended recipient, please be advised that distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete or destroy all copies of this message.

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] API stability policy for major vs minor vs patch releases

Diego Didona
Hi Erik!
I'm a little bit off-topic but I would like to ask you what do you mean
by "redirection". Can you explain it to me?
Thanks
   Diego

> +1.5B
>
> This method is a core component of my local transaction/redirection implementation.  Hopefully, this was an oversight and not intended to be removed.
>
> Erik
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of Paul Ferraro
> Sent: Wednesday, February 23, 2011 12:01 PM
> To: [hidden email]
> Subject: [infinispan-dev] API stability policy for major vs minor vs patch releases
>
> In my course of upgrading AS6 from 4.2.0.Final to 4.2.1.CR3, I came across a NoSuchMethodError.  Specifically, a couple AS components utilize DistributionManager.isLocal(String), which was dropped from the public API sometime after 4.2.1.CR1.
>
> While the fix is trivial enough (in the end I'll need to perform several component release to compensate), this raises the larger issue of a API stability policy for major vs minor vs patch releases.  At the very least, I don't think its wise to remove methods from a public interface in a patch release.  In my opinion, removing methods from a public API should only happen across major releases, and even then, only after being formally deprecated.
>
> Thoughts?
>
> Paul
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> The information contained in this message is legally privileged and confidential, and is intended for the individual or entity to whom it is addressed (or their designee). If this message is read by anyone other than the intended recipient, please be advised that distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete or destroy all copies of this message.
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] API stability policy for major vs minor vs patch releases

Galder Zamarreno
In reply to this post by Paul Ferraro
It's the result of https://issues.jboss.org/browse/ISPN-925 and http://goo.gl/MUJaK

I think it was an oversight. I agree that it should have been deprecated and removed in Infinispan 6.0.

I've created a JIRA to restore it and mark it as deprecated: https://issues.jboss.org/browse/ISPN-953

On Feb 23, 2011, at 6:00 PM, Paul Ferraro wrote:

> In my course of upgrading AS6 from 4.2.0.Final to 4.2.1.CR3, I came
> across a NoSuchMethodError.  Specifically, a couple AS components
> utilize DistributionManager.isLocal(String), which was dropped from the
> public API sometime after 4.2.1.CR1.
>
> While the fix is trivial enough (in the end I'll need to perform several
> component release to compensate), this raises the larger issue of a API
> stability policy for major vs minor vs patch releases.  At the very
> least, I don't think its wise to remove methods from a public interface
> in a patch release.  In my opinion, removing methods from a public API
> should only happen across major releases, and even then, only after
> being formally deprecated.
>
> Thoughts?
>
> Paul
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] API stability policy for major vs minor vs patch releases

Paul Ferraro
I had a hunch that might be the case - I'll hold off on testing until
ISPN-953 is resolved.
Thanks Galder,

Paul

On Thu, 2011-02-24 at 11:37 +0100, Galder Zamarreño wrote:

> It's the result of https://issues.jboss.org/browse/ISPN-925 and http://goo.gl/MUJaK
>
> I think it was an oversight. I agree that it should have been deprecated and removed in Infinispan 6.0.
>
> I've created a JIRA to restore it and mark it as deprecated: https://issues.jboss.org/browse/ISPN-953
>
> On Feb 23, 2011, at 6:00 PM, Paul Ferraro wrote:
>
> > In my course of upgrading AS6 from 4.2.0.Final to 4.2.1.CR3, I came
> > across a NoSuchMethodError.  Specifically, a couple AS components
> > utilize DistributionManager.isLocal(String), which was dropped from the
> > public API sometime after 4.2.1.CR1.
> >
> > While the fix is trivial enough (in the end I'll need to perform several
> > component release to compensate), this raises the larger issue of a API
> > stability policy for major vs minor vs patch releases.  At the very
> > least, I don't think its wise to remove methods from a public interface
> > in a patch release.  In my opinion, removing methods from a public API
> > should only happen across major releases, and even then, only after
> > being formally deprecated.
> >
> > Thoughts?
> >
> > Paul
> >
> > _______________________________________________
> > infinispan-dev mailing list
> > [hidden email]
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
> Galder Zamarreño
> Sr. Software Engineer
> Infinispan, JBoss Cache
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev



_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] API stability policy for major vs minor vs patch releases

Erik Salter
In reply to this post by Diego Didona
Responding to this here in case it's interesting to other members.

I'm using some of the new features introduced in 4.2 to really boost performance.

My distributed cache nodes expose their business logic -- consisting of multiple ISPN caches -- via REST.   There is a very high data contention rate that acquiring a cluster-wide lock is too expensive.  Also, a single business operation touches multiple caches, each with their own natural keys.

So to get the throughput I needed:

1.  I used ISPN's "eagerLockSingleNode" option.  There's an explanation on the Wiki about it.
2.  I made sure that the keys across multiple caches would be collocated, even across a rehash.  I had to create a custom key container that would return the same hash code.  There is no guarantee that two keys generated by ISPN's key factory would be on the same node after a rehash.
3.  The DistributionMangerImpl allows you to get the owner of a key -- and whether a key "isLocal()".   So since I'm using HTTP, I can examine the request, get the keys, and find out who owns them.  I can then  send a redirect (30x) back to the clients, and they forward the request to the data owner.
4.  Because of the ISPN configuration, I now can start a transaction on the data owner and acquire only local locks.

This improved throughput in my system considerably -- almost by a 4x factor.

Hope this helps.

Erik

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Diego Didona
Sent: Wednesday, February 23, 2011 5:52 PM
To: infinispan -Dev List
Subject: Re: [infinispan-dev] API stability policy for major vs minor vs patch releases

Hi Erik!
I'm a little bit off-topic but I would like to ask you what do you mean by "redirection". Can you explain it to me?
Thanks
   Diego

> +1.5B
>
> This method is a core component of my local transaction/redirection implementation.  Hopefully, this was an oversight and not intended to be removed.
>
> Erik
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Paul
> Ferraro
> Sent: Wednesday, February 23, 2011 12:01 PM
> To: [hidden email]
> Subject: [infinispan-dev] API stability policy for major vs minor vs
> patch releases
>
> In my course of upgrading AS6 from 4.2.0.Final to 4.2.1.CR3, I came across a NoSuchMethodError.  Specifically, a couple AS components utilize DistributionManager.isLocal(String), which was dropped from the public API sometime after 4.2.1.CR1.
>
> While the fix is trivial enough (in the end I'll need to perform several component release to compensate), this raises the larger issue of a API stability policy for major vs minor vs patch releases.  At the very least, I don't think its wise to remove methods from a public interface in a patch release.  In my opinion, removing methods from a public API should only happen across major releases, and even then, only after being formally deprecated.
>
> Thoughts?
>
> Paul
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> The information contained in this message is legally privileged and confidential, and is intended for the individual or entity to whom it is addressed (or their designee). If this message is read by anyone other than the intended recipient, please be advised that distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete or destroy all copies of this message.
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev

The information contained in this message is legally privileged and confidential, and is intended for the individual or entity to whom it is addressed (or their designee). If this message is read by anyone other than the intended recipient, please be advised that distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete or destroy all copies of this message.

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] API stability policy for major vs minor vs patch releases

Pete Muir
In reply to this post by Erik Salter
AIUI the issue is not that the method was removed (it was refactored to dm.getLocality().isLocal()) but just that an API change in the micro series is not allowed.

On 23 Feb 2011, at 18:19, Erik Salter wrote:

> +1.5B
>
> This method is a core component of my local transaction/redirection implementation.  Hopefully, this was an oversight and not intended to be removed.
>
> Erik
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of Paul Ferraro
> Sent: Wednesday, February 23, 2011 12:01 PM
> To: [hidden email]
> Subject: [infinispan-dev] API stability policy for major vs minor vs patch releases
>
> In my course of upgrading AS6 from 4.2.0.Final to 4.2.1.CR3, I came across a NoSuchMethodError.  Specifically, a couple AS components utilize DistributionManager.isLocal(String), which was dropped from the public API sometime after 4.2.1.CR1.
>
> While the fix is trivial enough (in the end I'll need to perform several component release to compensate), this raises the larger issue of a API stability policy for major vs minor vs patch releases.  At the very least, I don't think its wise to remove methods from a public interface in a patch release.  In my opinion, removing methods from a public API should only happen across major releases, and even then, only after being formally deprecated.
>
> Thoughts?
>
> Paul
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> The information contained in this message is legally privileged and confidential, and is intended for the individual or entity to whom it is addressed (or their designee). If this message is read by anyone other than the intended recipient, please be advised that distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete or destroy all copies of this message.
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] API stability policy for major vs minor vs patch releases

Diego Didona
In reply to this post by Erik Salter
Thank you very much.
So actually the redirection is not transparent to the client, nor there
is a "run time" redirection, since the client declares in the HTTP
request the keys it's going to use.
If this last sentence is correct, for the time being I don't have any
further question. Thank you for your explanation.
Regards,
    Diego

> Responding to this here in case it's interesting to other members.
>
> I'm using some of the new features introduced in 4.2 to really boost performance.
>
> My distributed cache nodes expose their business logic -- consisting of multiple ISPN caches -- via REST.   There is a very high data contention rate that acquiring a cluster-wide lock is too expensive.  Also, a single business operation touches multiple caches, each with their own natural keys.
>
> So to get the throughput I needed:
>
> 1.  I used ISPN's "eagerLockSingleNode" option.  There's an explanation on the Wiki about it.
> 2.  I made sure that the keys across multiple caches would be collocated, even across a rehash.  I had to create a custom key container that would return the same hash code.  There is no guarantee that two keys generated by ISPN's key factory would be on the same node after a rehash.
> 3.  The DistributionMangerImpl allows you to get the owner of a key -- and whether a key "isLocal()".   So since I'm using HTTP, I can examine the request, get the keys, and find out who owns them.  I can then  send a redirect (30x) back to the clients, and they forward the request to the data owner.
> 4.  Because of the ISPN configuration, I now can start a transaction on the data owner and acquire only local locks.
>
> This improved throughput in my system considerably -- almost by a 4x factor.
>
> Hope this helps.
>
> Erik
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of Diego Didona
> Sent: Wednesday, February 23, 2011 5:52 PM
> To: infinispan -Dev List
> Subject: Re: [infinispan-dev] API stability policy for major vs minor vs patch releases
>
> Hi Erik!
> I'm a little bit off-topic but I would like to ask you what do you mean by "redirection". Can you explain it to me?
> Thanks
>     Diego
>> +1.5B
>>
>> This method is a core component of my local transaction/redirection implementation.  Hopefully, this was an oversight and not intended to be removed.
>>
>> Erik
>>
>> -----Original Message-----
>> From: [hidden email]
>> [mailto:[hidden email]] On Behalf Of Paul
>> Ferraro
>> Sent: Wednesday, February 23, 2011 12:01 PM
>> To: [hidden email]
>> Subject: [infinispan-dev] API stability policy for major vs minor vs
>> patch releases
>>
>> In my course of upgrading AS6 from 4.2.0.Final to 4.2.1.CR3, I came across a NoSuchMethodError.  Specifically, a couple AS components utilize DistributionManager.isLocal(String), which was dropped from the public API sometime after 4.2.1.CR1.
>>
>> While the fix is trivial enough (in the end I'll need to perform several component release to compensate), this raises the larger issue of a API stability policy for major vs minor vs patch releases.  At the very least, I don't think its wise to remove methods from a public interface in a patch release.  In my opinion, removing methods from a public API should only happen across major releases, and even then, only after being formally deprecated.
>>
>> Thoughts?
>>
>> Paul
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>> The information contained in this message is legally privileged and confidential, and is intended for the individual or entity to whom it is addressed (or their designee). If this message is read by anyone other than the intended recipient, please be advised that distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete or destroy all copies of this message.
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> The information contained in this message is legally privileged and confidential, and is intended for the individual or entity to whom it is addressed (or their designee). If this message is read by anyone other than the intended recipient, please be advised that distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete or destroy all copies of this message.
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


--
Diego Didona
GSD INESC-ID

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] API stability policy for major vs minor vs patch releases

Manik Surtani
In reply to this post by Pete Muir
Well, the whole problem is that isLocal() is incorrect and returns inaccurate results.  Unfortunately the fix does involve an API change - but I agree that the API should be backward compatible.  I'll make sure the method is restored and marked as deprecated, but please use getLocality() instead.  :-)


 
On 24 Feb 2011, at 16:30, Pete Muir wrote:

AIUI the issue is not that the method was removed (it was refactored to dm.getLocality().isLocal()) but just that an API change in the micro series is not allowed.

On 23 Feb 2011, at 18:19, Erik Salter wrote:

+1.5B

This method is a core component of my local transaction/redirection implementation.  Hopefully, this was an oversight and not intended to be removed.

Erik

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Paul Ferraro
Sent: Wednesday, February 23, 2011 12:01 PM
To: [hidden email]
Subject: [infinispan-dev] API stability policy for major vs minor vs patch releases

In my course of upgrading AS6 from 4.2.0.Final to 4.2.1.CR3, I came across a NoSuchMethodError.  Specifically, a couple AS components utilize DistributionManager.isLocal(String), which was dropped from the public API sometime after 4.2.1.CR1.

While the fix is trivial enough (in the end I'll need to perform several component release to compensate), this raises the larger issue of a API stability policy for major vs minor vs patch releases.  At the very least, I don't think its wise to remove methods from a public interface in a patch release.  In my opinion, removing methods from a public API should only happen across major releases, and even then, only after being formally deprecated.

Thoughts?

Paul

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev

The information contained in this message is legally privileged and confidential, and is intended for the individual or entity to whom it is addressed (or their designee). If this message is read by anyone other than the intended recipient, please be advised that distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete or destroy all copies of this message.

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev



_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] API stability policy for major vs minor vs patch releases

Manik Surtani
Done

https://github.com/infinispan/infinispan/commit/0f06d3667bec0b514c6a00a3464094a6edecd704


On 1 Mar 2011, at 10:35, Manik Surtani wrote:

Well, the whole problem is that isLocal() is incorrect and returns inaccurate results.  Unfortunately the fix does involve an API change - but I agree that the API should be backward compatible.  I'll make sure the method is restored and marked as deprecated, but please use getLocality() instead.  :-)


 
On 24 Feb 2011, at 16:30, Pete Muir wrote:

AIUI the issue is not that the method was removed (it was refactored to dm.getLocality().isLocal()) but just that an API change in the micro series is not allowed.

On 23 Feb 2011, at 18:19, Erik Salter wrote:

+1.5B

This method is a core component of my local transaction/redirection implementation.  Hopefully, this was an oversight and not intended to be removed.

Erik

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Paul Ferraro
Sent: Wednesday, February 23, 2011 12:01 PM
To: [hidden email]
Subject: [infinispan-dev] API stability policy for major vs minor vs patch releases

In my course of upgrading AS6 from 4.2.0.Final to 4.2.1.CR3, I came across a NoSuchMethodError.  Specifically, a couple AS components utilize DistributionManager.isLocal(String), which was dropped from the public API sometime after 4.2.1.CR1.

While the fix is trivial enough (in the end I'll need to perform several component release to compensate), this raises the larger issue of a API stability policy for major vs minor vs patch releases.  At the very least, I don't think its wise to remove methods from a public interface in a patch release.  In my opinion, removing methods from a public API should only happen across major releases, and even then, only after being formally deprecated.

Thoughts?

Paul

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev

The information contained in this message is legally privileged and confidential, and is intended for the individual or entity to whom it is addressed (or their designee). If this message is read by anyone other than the intended recipient, please be advised that distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete or destroy all copies of this message.

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev



_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] API stability policy for major vs minor vs patch releases

Paul Ferraro
I see - thanks for the clarification.
So, to getLocality() is essentially an atomic composite of isLocal(...)
and isRehashInProgress(), correct?

On Tue, 2011-03-01 at 11:16 +0000, Manik Surtani wrote:

> Done
>
>
> https://github.com/infinispan/infinispan/commit/0f06d3667bec0b514c6a00a3464094a6edecd704
>
>
>
> On 1 Mar 2011, at 10:35, Manik Surtani wrote:
>
> > Well, the whole problem is that isLocal() is incorrect and returns
> > inaccurate results.  Unfortunately the fix does involve an API
> > change - but I agree that the API should be backward compatible.
> >  I'll make sure the method is restored and marked as deprecated, but
> > please use getLocality() instead.  :-)
> >
> >
> > http://docs.jboss.org/infinispan/4.2/apidocs/org/infinispan/distribution/DistributionManager.html#getLocality(java.lang.Object)
> >
> >
> >  
> > On 24 Feb 2011, at 16:30, Pete Muir wrote:
> >
> > > AIUI the issue is not that the method was removed (it was
> > > refactored to dm.getLocality().isLocal()) but just that an API
> > > change in the micro series is not allowed.
> > >
> > > On 23 Feb 2011, at 18:19, Erik Salter wrote:
> > >
> > > > +1.5B
> > > >
> > > > This method is a core component of my local
> > > > transaction/redirection implementation.  Hopefully, this was an
> > > > oversight and not intended to be removed.
> > > >
> > > > Erik
> > > >
> > > > -----Original Message-----
> > > > From: [hidden email]
> > > > [mailto:[hidden email]] On Behalf Of
> > > > Paul Ferraro
> > > > Sent: Wednesday, February 23, 2011 12:01 PM
> > > > To: [hidden email]
> > > > Subject: [infinispan-dev] API stability policy for major vs
> > > > minor vs patch releases
> > > >
> > > > In my course of upgrading AS6 from 4.2.0.Final to 4.2.1.CR3, I
> > > > came across a NoSuchMethodError.  Specifically, a couple AS
> > > > components utilize DistributionManager.isLocal(String), which
> > > > was dropped from the public API sometime after 4.2.1.CR1.
> > > >
> > > > While the fix is trivial enough (in the end I'll need to perform
> > > > several component release to compensate), this raises the larger
> > > > issue of a API stability policy for major vs minor vs patch
> > > > releases.  At the very least, I don't think its wise to remove
> > > > methods from a public interface in a patch release.  In my
> > > > opinion, removing methods from a public API should only happen
> > > > across major releases, and even then, only after being formally
> > > > deprecated.
> > > >
> > > > Thoughts?
> > > >
> > > > Paul
> > > >
> > > > _______________________________________________
> > > > infinispan-dev mailing list
> > > > [hidden email]
> > > > https://lists.jboss.org/mailman/listinfo/infinispan-dev
> > > >
> > > > The information contained in this message is legally privileged
> > > > and confidential, and is intended for the individual or entity
> > > > to whom it is addressed (or their designee). If this message is
> > > > read by anyone other than the intended recipient, please be
> > > > advised that distribution of this message, in any form, is
> > > > strictly prohibited. If you have received this message in error,
> > > > please notify the sender immediately and delete or destroy all
> > > > copies of this message.
> > > >
> > > > _______________________________________________
> > > > infinispan-dev mailing list
> > > > [hidden email]
> > > > https://lists.jboss.org/mailman/listinfo/infinispan-dev
> > >
> > >
> > > _______________________________________________
> > > infinispan-dev mailing list
> > > [hidden email]
> > > https://lists.jboss.org/mailman/listinfo/infinispan-dev
> > >
> >
> > --
> > Manik Surtani
> > [hidden email]
> > twitter.com/maniksurtani
> >
> >
> > Lead, Infinispan
> > http://www.infinispan.org
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > infinispan-dev mailing list
> > [hidden email]
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
> Manik Surtani
> [hidden email]
> twitter.com/maniksurtani
>
>
> Lead, Infinispan
> http://www.infinispan.org
>
>
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] API stability policy for major vs minor vs patch releases

Manik Surtani

On 2 Mar 2011, at 19:45, Paul Ferraro wrote:

> I see - thanks for the clarification.
> So, to getLocality() is essentially an atomic composite of isLocal(...)
> and isRehashInProgress(), correct?

Pretty much.  :)

--
Manik Surtani
[hidden email]
twitter.com/maniksurtani

Lead, Infinispan
http://www.infinispan.org



_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev