Re: [VOTE] Release Apache UIMA uimaFIT 2.3.1 RC 1

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

my feeling after using semver for a while is that there were multiple cases
where I was "temporarily" adding exceptions to the POM because of changes which
I didn't feel warranted bumping up a higher digit.

These were often changes which added a method to an existing class, where that
method was very unlikely to be already implemented in a subclass that the user
might have written.

So, my feeling is to run this new report, which I thought provided useful
details to our users, if nothing else, by listing all the new and changed
things, and then make a judgement about what to do with respect to the version
number.  I think the default report shows what japicmp thinks the version should
be according to semver rules, so it's easy to check manually, as well as
automatically.

And, of course, those that want their builds to default to breaking the build
when semver rules are violated can configure that.

-Marshall


On 5/31/2017 5:41 PM, Richard Eckart de Castilho wrote:
> On 31.05.2017, at 17:16, Marshall Schor <ms...@schor.com> wrote:
>> I think not a blocker: this release includes uimaj-core at version 2.10.0, and
>> other components in extras/ at the 2.10.0 level.
>>
>> The README doesn't mention this, and says "uimaFIT requires ...  UIMA 2.9.0 or
>> higher ... "
> *sigh*... looks like for some reason I set back all references to uimaj-core 2.9.0
> (as we had discussed on the list) *except* the variable in the POM. No idea how 
> that slipped through.
>
> I guess that means cancelling again and doing an RC2.
>
> But before that I would like to resolve the discussion around the API reports
> and whether or not the new API plugin that we are using does the same kind of
> semantic versioning checks as the semver plugin did. I had somehow assumed that
> it did, but looking at the documentation now, it seems that these checks are
> turned off by default:
>
> https://siom79.github.io/japicmp/MavenPlugin.html
>
> breakBuildBasedOnSemanticVersioning is per default set to false.
>
> I thought that the semver plugin had been replaced because the new one provides
> better reports. But really, these reports are tedious to read. Shouldn't we
> enable "breakBuildBasedOnSemanticVersioning" to get warned again of cases were
> we increase the version number less than semantic versioning would mandate?
>
> Cheers,
>
> -- Richard

[CANCEL] [VOTE] Release Apache UIMA uimaFIT 2.3.1 RC 1

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

So I'll re-do the release properly against UIMA 2.9.1
and after enhancing the api checking configuration.

Stay tuned...

-- Richard

Re: [VOTE] Release Apache UIMA uimaFIT 2.3.1 RC 1

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

On 08.06.2017, at 09:19, Peter Klügl <pe...@averbis.com> wrote:
> 
> This there progress on this matter? I'd prefer us to use the same
> approach/checks within the uima projects but it should not be a stopper
> for a release.

It is on my todo list. So what I plan to do is to enable the semver checks
in the new plugin and have the build fail if semver rules are violated.

For good measure, I might also reactivate the old semver plugin to run it
in parallel with the new one for some time to get a better feeling.

I think I would use the semver plugin to compare against the earliest
version possible and the new plugin to compare against the closest release.

Can anybody point towards how to create the aggregated api report? I
thought that I had copied over all the configuration for the new plugin
into uimaFIT, but as Marshall pointed out repeatedly, there seems to be
no aggregated report.

Cheers,

-- Richard

Re: [VOTE] Release Apache UIMA uimaFIT 2.3.1 RC 1

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

This there progress on this matter? I'd prefer us to use the same
approach/checks within the uima projects but it should not be a stopper
for a release.


Am 01.06.2017 um 15:42 schrieb Marshall Schor:
> my feeling after using semver for a while is that there were multiple cases
> where I was "temporarily" adding exceptions to the POM because of changes which
> I didn't feel warranted bumping up a higher digit.
>
> These were often changes which added a method to an existing class, where that
> method was very unlikely to be already implemented in a subclass that the user
> might have written.
>
> So, my feeling is to run this new report, which I thought provided useful
> details to our users, if nothing else, by listing all the new and changed
> things, and then make a judgement about what to do with respect to the version
> number.  I think the default report shows what japicmp thinks the version should
> be according to semver rules, so it's easy to check manually, as well as
> automatically.
>
> And, of course, those that want their builds to default to breaking the build
> when semver rules are violated can configure that.
>
> -Marshall
>
>
> On 5/31/2017 5:41 PM, Richard Eckart de Castilho wrote:
>> On 31.05.2017, at 17:16, Marshall Schor <ms...@schor.com> wrote:
>>> I think not a blocker: this release includes uimaj-core at version 2.10.0, and
>>> other components in extras/ at the 2.10.0 level.
>>>
>>> The README doesn't mention this, and says "uimaFIT requires ...  UIMA 2.9.0 or
>>> higher ... "
>> *sigh*... looks like for some reason I set back all references to uimaj-core 2.9.0
>> (as we had discussed on the list) *except* the variable in the POM. No idea how 
>> that slipped through.
>>
>> I guess that means cancelling again and doing an RC2.
>>
>> But before that I would like to resolve the discussion around the API reports
>> and whether or not the new API plugin that we are using does the same kind of
>> semantic versioning checks as the semver plugin did. I had somehow assumed that
>> it did, but looking at the documentation now, it seems that these checks are
>> turned off by default:
>>
>> https://siom79.github.io/japicmp/MavenPlugin.html
>>
>> breakBuildBasedOnSemanticVersioning is per default set to false.
>>
>> I thought that the semver plugin had been replaced because the new one provides
>> better reports. But really, these reports are tedious to read. Shouldn't we
>> enable "breakBuildBasedOnSemanticVersioning" to get warned again of cases were
>> we increase the version number less than semantic versioning would mandate?
>>
>> Cheers,
>>
>> -- Richard