[CANCEL] [VOTE] Release Apache UIMA uimaFIT 2.4.0 RC 2

[Richard Eckart de Castilho <re...@apache.org>]

On 17.05.2017, at 20:41, Marshall Schor <ms...@schor.com> wrote:
> 
> 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.

We could turn uimaFIT into a module of uimaj ;) Then we'd have
only once release cycle. When uimaFIT was contributed, I was expecting that
uimaFIT would be released more often than uimaj-core and I wanted to be able
to have these faster release cycles. However, in reality, it turns out this
was wishful thinking. At least at the moment, I rather manage to do less
releases than Marshall.  

> 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.

I didn't feel comfortable upgrading the uimaj-core dependency to 2.10.0 and then
only to increase the last digit. If felt that it would have been less customer-friendly
to do that then to increase the middle number.

Anyway, it was probably a bad idea anyway as Peter has pointed out.

I'll do prepare a 2.3.1 that depends on uimaj-core 2.9.0.

-- Richard

Re: [CANCEL] [VOTE] Release Apache UIMA uimaFIT 2.4.0 RC 2

[Peter Klügl <pe...@averbis.com>]

Hi,


Am 17.05.2017 um 21:15 schrieb Richard Eckart de Castilho:
>
> We could turn uimaFIT into a module of uimaj ;)

+1 :-)

>
> I didn't feel comfortable upgrading the uimaj-core dependency to 2.10.0 and then
> only to increase the last digit. If felt that it would have been less customer-friendly
> to do that then to increase the middle number.
>
> Anyway, it was probably a bad idea anyway as Peter has pointed out.


Argh.... I did not want to point out anything, especially I did not want
you cancelling the rc. My intention was just to decide if the next ruta
release is a bugfix or a minor one. I am totally fine if we do a minor
in case the uima version is upgraded to a new minor version. I would
like to see that the uima projects use somewhat the same strategy when
selecting the next release number, but I am also fine if there are
differences.


Best,


Peter

Re: [CANCEL] [VOTE] Release Apache UIMA uimaFIT 2.4.0 RC 2

[Richard Eckart de Castilho <re...@apache.org>]

On 17.05.2017, at 22:43, Marshall Schor <ms...@schor.com> wrote:
> 
> Do you think the proposed 2.3.1 that depends on uimaj 2.9.0
> could instead depend on uimaj 2.9.0 or 2.10.0?

You mean a dependency with a version range? I don't like version
ranges in POMs because they make the build less reproducible.

-- Richard

Re: [CANCEL] [VOTE] Release Apache UIMA uimaFIT 2.4.0 RC 2

[Marshall Schor <ms...@schor.com>]

Do you think the proposed 2.3.1 that depends on uimaj 2.9.0
could instead depend on uimaj 2.9.0 or 2.10.0?

-M


On 5/17/2017 3:15 PM, Richard Eckart de Castilho wrote:
> On 17.05.2017, at 20:41, Marshall Schor <ms...@schor.com> wrote:
>> 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.
> We could turn uimaFIT into a module of uimaj ;) Then we'd have
> only once release cycle. When uimaFIT was contributed, I was expecting that
> uimaFIT would be released more often than uimaj-core and I wanted to be able
> to have these faster release cycles. However, in reality, it turns out this
> was wishful thinking. At least at the moment, I rather manage to do less
> releases than Marshall.  
>
>> 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.
> I didn't feel comfortable upgrading the uimaj-core dependency to 2.10.0 and then
> only to increase the last digit. If felt that it would have been less customer-friendly
> to do that then to increase the middle number.
>
> Anyway, it was probably a bad idea anyway as Peter has pointed out.
>
> I'll do prepare a 2.3.1 that depends on uimaj-core 2.9.0.
>
> -- Richard