db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David W. Van Couvering" <David.Vancouver...@Sun.COM>
Subject Re: Versioning and features
Date Fri, 23 Sep 2005 00:23:49 GMT
Well, I thought this wouldn't get attention until I announced something, 
but I discovered that every mod I make to a Wiki page gets broadcasted 
to the committers list (sorry all for the slew of emails).  I'm not sure 
if the alias should be subscribed, maybe individuals could subscribe as 
desired?

Anyway, as Jeremy mentions, I put up a Wiki page for a draft version of 
the versioning guidelines and an associated review page.  The idea of 
the review page is to get your comments recorded there and allow for 
discussion without a huge email thread.  This also makes sure each 
comment gets tracked and not lost.

So, I welcome your comments.  The draft guidelines are at

http://wiki.apache.org/db-derby/ModuleVersioningGuidelines

and the associated review page is at

http://wiki.apache.org/db-derby/ModuleVersioningGuidelinesReview

Jeremy, I'm going to add your comment below to the review page (and will 
respond there) when I get a chance, a bit on the run right now.

Thanks, I hope this works better than our poor old derby-dev alias for 
getting proposals like this reviewed and resolved.

David

Jeremy Boynes wrote:
> 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