Use-cases for version ranges?

[Brian Pontarelli]

On Nov 21, 2011, at 1:36 PM, Tim Diekmann wrote:

>> 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.
> 
> But did it work or cause other problems?

It had a number of issues including:

- Readability
- Maintainability
- Consistency

It's hard to get everyone to do the right thing and ensure it is always perfect. It is much simpler for people to just modify the base interface. Plus, most tools don't really like this all that much and it is hard to figure out where you are at and what is available.

In the end, we ended up dropping the interface versioning system and go back to using a single interface with a version compatibility system I created that dictated how things could change and how to version things. We then used the Package version information to publish and find services in Jini and make version checks at runtime. This allowed us to update services with no downtime and not require the entire system to be re-compiled/updated. Only the pieces of the system that needed the new version of the service needed to be updated.

-bp