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
begin:vcard
fn:David W Van Couvering
n:Van Couvering;David W
org:Sun Microsystems, Inc.;Database Technology Group
email;internet:[EMAIL PROTECTED]
title:Senior Staff Software Engineer
tel;work:510-550-6819
tel;cell:510-684-7281
x-mozilla-html:TRUE
version:2.1
end:vcard
