Hi
Pedantically, adding and exploiting @noimplement requires a major
version change anyway, but if we did that for every "oops, that should
not have been API" we would always need major version changes.
Practically, I find that the improved API checking for name addition in
M6 makes non-majo
Well API-Tooling is correct! There is a method added to an interface who
was NOT marked @noimplement, so this is a source breaking change (binary
is ok!).
In general I think we should (re)instruct all our committers to think
twice before upgrading the major version of a bundle and get in touch
wit
I don't understand why the API tooling recommended a major increment since
there was no breaking change — they were all API additions.
Given that it's been in place for 10 days, my vote is to recover from the
mistake and fix the version number.
Brian.
> On 13-Mar-2017, at 6:07 AM, Simon Schol
Hello,
from my side I´ve just been following the checks of the API Base Line
tooling accroding to the changes in the generated code of the MUiFactory
class.
So at least we should add the noimplement flag to the MUiFactory to avoid
further major version increments due to the missing noimplement fla
Hi
Chaotic major versions seem undesirable, so since the major version has
not yet made it to +4 on any milestone it seems appropriate to revert
it; preferably for M6, but certainly for M7.
We aggregate to find inconsistencies. We found one, the platform was
wrong, the platform should correc
Thanks Tom! That was my thinking too. So, that class should be marked as
@noimplement in the model, because next time, PDE Tools will again ask the
developer to increment the major version.
Unfortunately, at this point, reverting the major version increase seems
to do more harm than having a f
