I think using the semver plugin is a good thing to make us aware of changes that should increase the version at different level. I also think it motivates us to not just keep on updating the patch-level version because we are modest.
I do not think the two changes that you mention warrant a minor-level version increase. But I would ask whether the 2.8.2 release is really just a bug-fix release or whether it includes any new features. If there are new features, I would prefer version 2.9.0. I believe increasing the version at the minor level should be the default. Best, -- Richard > On 15.07.2016, at 16:53, Marshall Schor <[email protected]> wrote: > > 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) >> >
