why not simply use x-unsupported then to make it really clear? ;-)
Is such x-unsupported already used by some other projects? If so, it wouldn't be a bad thing to use it. But that's exactly the meaning of x-internal though and I don't think we can say that x-internal + the warnings is generate are ambiguous. So I'm not sure changing the flag would improve anything, unless it's more standard.
Or simply adopt API guardian here:
https://github.com/eclipse-m2e/m2e-core/discussions/566
I'm not convinced that "1 more non-standard technology" is the solution here. Why would APIGuardian help here when you already say we don't even do package versioning properly? APIGuardian require clients to care about it, if most clients (connectors) don't care about package/bundle versions already, why can we expect they'll care about APIGuardian annotations?
There is
https://github.com/bndtools/bnd/tree/master/maven/bnd-baseline-maven-plugin and I created
https://github.com/eclipse/tycho/issues/115
That's interesting, but this would better be directly in the IDE. Is the BND Eclipse plugin capable of baselining?
Actually we should have all the bits there as we can already do a
pde-api-tools check so a semver check would just replace pde-api-tools
with bnd call, one might even be able to use the bnd-mvan plugin alone
and just injecting the <base> configuration for convenience
That would be a very interesting topic, worth articles and conference presentations as well. If we can have better baselining thanks to BND than what PDE offers and still fits in the Eclipse needs, then it means we can progressively drop PDE API Tools in favor of BND. One less thing to maintain, more focus on 1 better solution ;)
