You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by "Marshall Schor (JIRA)" <de...@uima.apache.org> on 2016/07/15 13:54:20 UTC
[jira] [Created] (UIMA-5014) uimaj - change next release version to
2.9.0 from 2.8.2
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)
Re: [jira] [Created] (UIMA-5014) uimaj - change next release version to 2.9.0 from 2.8.2
Posted by Richard Eckart de Castilho <re...@apache.org>.
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 <ms...@schor.com> 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)
>>
>
Re: [jira] [Created] (UIMA-5014) uimaj - change next release version to 2.9.0 from 2.8.2
Posted by Richard Eckart de Castilho <re...@apache.org>.
Because it is convenient, in DKPro Core we added variants of the Java
serialization-based format and of form 6 that include type system information.
Would be nice to add these to the CAS Editor as well.
We also have code in the DKPro Core BinaryCasReader that auto-detects
the any of the binary formats and loads them. That code is Apache-licensed.
Cheers,
-- Richard
> On 15.07.2016, at 20:26, Peter Klügl <pe...@averbis.com> wrote:
>
> 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
Re: [jira] [Created] (UIMA-5014) uimaj - change next release version
to 2.9.0 from 2.8.2
Posted by Peter Klügl <pe...@averbis.com>.
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)
>>
Re: [jira] [Created] (UIMA-5014) uimaj - change next release version
to 2.9.0 from 2.8.2
Posted by Marshall Schor <ms...@schor.com>.
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)
>