Use-cases for version ranges?

[Brian Pontarelli]

On Nov 21, 2011, at 12:41 PM, cowwoc wrote:

> 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?

The naming convention is version based. It looks like:

interface Collections {}
interface Collections_1_2 extends Collections {}
interface Collections_1_2_1 extends Collections_1_2 {}
interface Collections_1_3 extends Collections_1_2_1 {}

We attempted this at Orbitz and it was not pretty in practice.

-bp