Versioning and features

[Jeremy Boynes <jb...@apache.org>]

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

Re: Versioning and features

["Jean T. Anderson" <jt...@bristowhill.com>]

David W. Van Couvering wrote:
> 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?

Don't worry about it. Change notifications should go somewhere.  Check 
other projects at http://mail-archives.apache.org/mod_mbox/ and you'll 
see that many interleave Wiki and repo changes on their commits/cvs list.

  -jean

Re: Versioning and features

["David W. Van Couvering" <Da...@Sun.COM>]

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