On Oct 2, 2006, at 12:01 PM, Frank Budinsky wrote:
Jeremy Boynes <[EMAIL PROTECTED]> wrote on 10/02/2006 02:43:22 PM:
On irc this morning the question came up about which version of the
spec the spec/sdo API related to. The conclusion was 2.0.1 + a couple
of methods from 2.1 but not all.
Is this the case?
Yes.
If so, are we allowed to release a jar which does not correspond to
an official version of the spec? I know this is major problem for
APIs from the JCP.
I don't know of anything that says we aren't.
If we are, do we want to do this? Would "good netizenship" imply that
we should keep versions in sync with published versions?
We are officially 2.0.1.
I would think in that case the API signature should match 2.0.1
rather than something undefined.
The only thing we've added from 2.1 is a couple of well marked new
methods
(names are still subject to change in the 2.1 spec). There is no
change to
any of the official 2.0.1 behavior. It shouldn't matter that we
added the
new methods since they won't affect users that don't call them.
They are
quite useful, however, for our own development.
Can we just add those to our implementation rather than to the spec
API (until we do spec 2.1 of course)? They do affect users of the
spec API as code may compile against this version but not work with
other implementations. Any other implementation would also be
affected as they would have undefined methods which would prevent
compilation.
Our next release (M3) will officially move to the 2.1 interfaces,
but we
won't be fully 2.1 compliant (e.g., some methods will throw
UnsupportedOpertationException). For that matter, we're also not fully
2.0.1 compliant now either.
It's OK for our implementation to be incomplete or to offer
additional features but I don't think we should bend the spec API
like this.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
