Putting myself in the position of a user of uimaFIT (and UIMA) v2: To upgrade myself to v3, for UIMA, I could migrate the JCas classes (if any), and then, without recompiling, just run using UIMA 3 (because UIMA 3 is "binary compatible" at the public API level (at least that was the goal :-) ).
I guess the uimaFIT v3 design probably requires some upgrade, and probably a recompile, for v3. I reran the build using 2.4.0 as the previous version, to get a sense of backwards compatibility issues. In general, it looks pretty good :-). I see that ...internal.ExtendedLogger class was removed, and other classes that might reference it were updated. This seems unlikely to cause user problems. One kind of change to CasUtil, JCasUtil, and FSCollectionFactory operations might cause user problems unless the user recompiles the code - these are changes which change the return type of select and selectFS, and create. Other changes which could be a problem is the removal of FSUtil's isMultiValuedFeature. If you're happy introducing these changes, then this is fine with me (not a blocker). You might want to augment the "migration guide" chapter 11.1 to include the removal of FSUtil's isMultiValuedFeature (and any other removed things a user might be using) (or add that back... :-) ). -Marshall On 1/24/2019 11:29 AM, Richard Eckart de Castilho wrote: > On 24. Jan 2019, at 16:43, Marshall Schor <[email protected]> wrote: >> I noticed the API compare reports ( japicmp ) are being calculated using >> version >> 2.1.0 (dates from 2014) >> Should this be uimaFIT 2.4.0? > Well, it probably should. But it also doesn't matter because it is a major > release anyway. It would be relevant if it were a bugfix release in order > to discover if there were any changes that would warrant upgrading it to > a feature release. For the next v3 version, this should be set to 3.0.0. > > -- Richard
