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 <[email protected]> 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
