I don't see this as a big deal, but if others feel strongly that it is bad, then we can take the two offensive methods out of the TypeHelper interface and cast to TypeHelperImpl in a couple of places. I'd suggest we just make this change in the release branch, so that the trunk is still set for 2.1.
Frank. Jeremy Boynes <[EMAIL PROTECTED]> wrote on 10/02/2006 04:00:17 PM: > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
