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
