2 thoughts:

1) if your component doesn't require 2.10.0, but works with a range of versions,
including 2.10.0, and

  - your component doesn't "include" core uima 2.10.0, then I think the version
numbering can be independent.

2) I suggest we be customer-focused, and try to have our version numbering
communicate useful information.  So, to me, if we have a bug-fix release that
doesn't change customer-facing APIs except for perhaps adding new signatures
(which are very unlikely to collide with user methods) , I would treat this as a
3-rd digit increment, because that communicates best what an upgrader ought to
expect.

-Marshall


On 5/17/2017 8:46 AM, Peter Klügl wrote:
> This is maybe off-topic here...
>
>
> Is the dependency to 2.10.0 hard/required for the uimaFIT functionality?
>
> I just wonder if I should plan ruta 2.7.0 instead of 2.6.1 since I also
> increase the uima version.
>
> Do we have some best practice here at uima? Update of dependency on
> minor level -> minor release?
>
>
> (As Richard once said: there are enough numbers. I do not care at all if
> I switch to minor. Maybe it should be consistent in the sub projects)
>
>
> Peter
>
>
>
> Am 16.05.2017 um 20:14 schrieb Richard Eckart de Castilho:
>> Hi all,
>>
>> this is a bugfix release (but upgrades to UIMA 2.10.0, that is why it's not 
>> 2.3.1):
>>
>> - Fixed bug: indexCovered should not return reference annotation
>> - Upgrade to UIMA 2.10.0
>>
>> Staging repository:
>>
>> https://repository.apache.org/content/repositories/orgapacheuima-1141
>>
>> SVN tag:
>>
>> https://svn.apache.org/repos/asf/uima/uimafit/tags/uimafit-2.4.0
>>
>> Release artifacts are here:
>>
>> https://dist.apache.org/repos/dist/dev/uima/uimafit-2.4.0-rc2/
>>
>> Overall 2 issues have been resolved for this release.
>> They can be found in the jira-report.html.
>>
>> ... and here:
>>
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20UIMA%20AND%20fixVersion%20%3D%202.4.0uimaFIT%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
>>
>> Please vote on release:
>>
>> [ ] +1 OK to release
>> [ ]  0 Don't care
>> [ ] -1 Not OK to release, because ...
>>
>> Cheers,
>>
>> -- Richard
>

Reply via email to