db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <jboy...@apache.org>
Subject Versioning and features
Date Thu, 22 Sep 2005 17:41:10 GMT
I mentioned in ModuleVersioningGuidelinesReview about a feature 
mechanism rather than version numbers and thought I should probably 
should explain that more.

The concern I had with version numbering is that there is a lot of 
implicit information locked up in a single String or int. As the 
objective of this is to cater for scenarios where there is skew between 
consumer and implementation I think it is better to make this more explicit.

To that end, I was envisioning a mechanism where the consumer could 
easily check if a specific feature was provided by the implementation 
rather than seeing which version was there and then inferring.

To achieve this, I was thinking the primary interface would have a 
method like:
     * @param className the class providing the feature
     * @param featureId the feature to check for
     * @return true if the implementation supports the requested feature
    boolean hasFeature(String className, String featureId)

This needs to be loosely coupled i.e. featureId Strings would be 
documented but the consumer could not rely e.g. on a constant field as 
that field may not be defined by earlier versions.


View raw message