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.

--
Jeremy

Mime
View raw message