Use-cases for version ranges?

[Eric Johnson]

Maybe I missed it, but I want to pick on one particular point, around 
which I've had discussions within my company.

On 11/20/11 4:09 AM, cowwoc wrote:
>     I'd like to propose another possibility: the author of the 
> dependency should tell *us* about version compatibility, not the other 
> way around. For example:
"compatibility" as defined by whom? Here's my description for some of 
the common compatibility notions.

"Classpath compatibility" - given a flat classpath, everything must be 
backwards compatible. You never add methods to existing interfaces. 
Adding methods to non-final public classes is likely inappropriate, but 
tolerable (name collision with a subclass will lead to unexpected behavior).

"JRE compatibility" - All existing methods still there. This is much 
weaker than Classpath compatible: my favorite example is the JDBC APIs, 
where the JDK has consistently added methods to the interfaces over the 
years, rather than extending the base interfaces. This means that anyone 
that ever does anything non-trivial with the JDBC API has to fix their 
code with every single JDK release. Even though it is allegedly compatible.

"Eclipse API Tools compatibility" - using annotations, under certain 
circumstances, I get to add methods to classes and interfaces. 
Otherwise, no. Versions specified at the module level.

"OSGi Compatibility" - applies at the package (well, or module, if you 
wish) level. As proposed (sorry, I need a reference here, but don't have 
it handy), a minor bump means you are adding methods to interfaces, and 
a major bump means backwardly incompatible. Unlike Eclipse API Tools, no 
annotations to cheat around the edges.

My own notion - combine "classpath compatibility" with a notion of 
version #, so that backwards incompatibility can be flagged. All other 
aspects of version # are strictly speaking an indication of scope of 
change (bug fix vs. additional functionality)

------

I personally argue strongly in favor of the "classpath compatibility" 
notion. That is, Java already has the ability to express a new version 
of an interface that adds a new method by simply having the new 
interface extend the old one. No fancy version schemes required, and the 
granularity works all the way down to the individual class/interface. If 
you do combine this with a version scheme, you can indicate backwards 
compatibility, and scope of change.

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.

-Eric.