Use-cases for version ranges?

[cowwoc]

Hi Eric,

On 21/11/2011 5:43 AM, Eric Johnson [via jigsaw-dev] wrote:
> Trouble is, the Java community doesn't seem to like the idea of a new
> named interface with the additional of even one method to an interface.
> But is that perhaps just because the JDK has acculturated people to the
> idea that they don't need to do that? It seems to me that any version
> scheme that attempts to cover up this problem will likely just add to
> the confusion, rather than resolve the problem. We either have to stick
> a stake in the ground and declare what we mean by backward compatible,
> or admit that there isn't a single notion, and therefore version ranges
> just mean what people want them to mean.

     My problem with this approach is java.util.Collections followed by 
Collections2 in Guava. Another example, Futures vs MoreFutures in Guava. 
These are examples of class subclassing, not interface extension, but 
the problem is the same: once you pick a good name it's extremely 
difficult to come up with yet another good name for the same thing. How 
many times do you think you could extend an interface before you run out 
of names? Twice? Three times maybe?

     I'm also tired of Java features having their designs crippled in 
the name of backwards-compatibility. I'm personally in favor of each 
author declaring a backwards compatibility policy and breaking 
compatibility as necessary. In the case of the JDK, you can imagine 
removing deprecated methods after 5 years. Projects like Guava give you 
6 months. The point is that you can't keep backwards compatibility 
forever, especially in light of the requirement you mentioned that 
developers may not add any new methods ;)

Gili


--
View this message in context: http://jigsaw-dev.1059479.n5.nabble.com/Use-cases-for-version-ranges-tp5002801p5011460.html
Sent from the jigsaw-dev mailing list archive at Nabble.com.