Hi,
I really like to see that the CAS Editor works with any UIMA supported serialization format, e.g., some specific binary format. We have some serious performance problems displaying large CAS files with many annotations (with the same offset). I could implement the required feature (or I could find someone), which would lead to some functionality DKPro provides. (If Richard contributes some code -> even better). It would be great if that functionality+utils class makes it into the next release. I just wanted to mention it in case there is enough time to implement it in the current roadmap ... and in case it would have some influence on the version. Best, Peter Am 15.07.2016 um 16:53 schrieb Marshall Schor: > I'm wondering if this version change is the right one. > > The semver.org website defines the rules in terms of backwards compatible > changes that are internal vs public. > > Unfortunately, Java's "public" definition is overloaded, in its use in UIMA: > > - APIs intended for use by the public > > - APIs not intended for use by the public, but which need to be public > because > they're referenced from different packages in Java, and no subclass > relationship > exists. > > We control some of this by having packages that have the word "impl" or > "internal" in them - these are excluded in the semantic versioning checking > already. > > In the current build of uimaj trunk, we are getting two "non backward > compatible" detections (which would, strictly speaking, require changing the > "X" > in "X.Y.Z" version). These are both more of the "internal" backwards > compatible > kind. > > One is a mistake in the definition of a constant that's likely not used by > users, and if used, would not work anyway - see UIMA-4565. The other is > adding > some more checking and therefore, and new error message. The error messages > are > put into CASRuntimeException as constants, and this is by default included in > the semantic version checking. I think it is an internal housekeeping thing > for > error messages, and not really intended for use by the public; it is "public" > only due to Java rules. I'd like to add it to the exclude list, treating it > like "impl" and "internal". > > So - the upshot of all this, if people agree, is that the semantic versioning > would not require moving from 2.8.1 -> 2.9.0; we could keep things at 2.8.2. > I > think that would be more consumable by our user community, because the changes > ought to be invisible (other than bugs being fixed) to them, and not require > them to change/adapt their code (the one exception being UIMA-AS which we > would > do, to handle UIMA-4743). > > What do others think? > > -Marshall > > On 7/15/2016 9:54 AM, Marshall Schor (JIRA) wrote: >> Marshall Schor created UIMA-5014: >> ------------------------------------ >> >> Summary: uimaj - change next release version to 2.9.0 from 2.8.2 >> Key: UIMA-5014 >> URL: https://issues.apache.org/jira/browse/UIMA-5014 >> Project: UIMA >> Issue Type: Task >> Components: Core Java Framework >> Reporter: Marshall Schor >> Assignee: Marshall Schor >> Priority: Minor >> >> >> Semantic versioning fails because we introduce a new error message. I'm not >> sure that qualifies, but the rules say that violates the >> increment-the-3rd-digit policy. >> >> Also, we'll be releasing a bug fix for binary delta cas serialization which >> produces an incompatible serialized form not readable by old uima versions. >> This will most likely be completely hidden by an update to uima-as, but is >> another reason to bump the middle number. See UIMA-4743 >> >> >> >> -- >> This message was sent by Atlassian JIRA >> (v6.3.4#6332) >>
