Hi Mathias, > To my knowledge we still didn't agree on doing incompatible changes > before 4.0.
Right, we only agreed to disagree :) In the concrete case, I think replacing the enum with an (extensible) constant group is better than introducing the FilterOperator2, which just adds clutter to the API. We would need to explicitly check this, but in my understanding the only language binding where this is (compile-time) incompatible is C++. In Java, it should be compile-time compatible, and perhaps even runtime-compatible. All other language bindings should be completely agnostic of such a change. Well, Stephan could probably point out some esoteric cases where this breaks ... Glad^Wsad he's on vacation currently :) > BTW: while changing enums currently is impossible without getting bitten > by our API compatibility watch dog, IIRC it tolerates extensions of > constant groups. Please correct me if I'm wrong. You aren't, to my knowledge. > Wouldn't it make sense to specify that constant groups are extensible > per se, so that each code dealing with them must be able to handle > unknown values? Perhaps with giving hints or specifying how unknown > values of a particular group should be treated? Yes, would be a reasonable general guideline. Not sure we have a place for such guidelines, though. > So constant groups could be changed at any time with good confidence, > without considering this to be "incompatible". Without this explicit > declaration adding constants to groups actually is incompatible, though > we didn't AFAIK consider it to be so when we already added numerous > constants to several groups. Does our watch dog bite when adding new constants to a *published* group? Never tried. Adding new constants to an unpublished group has never been a problem, by definition and in theory, since they were allowed to be changed incompatibly. Ciao Frank -- - Frank Schönheit, Software Engineer [email protected] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
