[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [m2e-dev] semantic versioning / Re: Starting a 2.0 with breaking changes soon?
|
> IMO, you're in between dogmatism and utopia here ;)
Its more pragmatism. One should ask why does it "hurt" to export a
package if it contains useful code. You can still name it "internal" and
blame anyone using it to be "bad people", because you have shaped your
code in a way that made it necessary to share that code.
> x-friends/x-internal
Is really strange, as a matter of fact we are all using these "non API
api" and simply adding suppress warnings (even inside m2e itself).
> without increasing the amount of
> publicly supported API
why not simply use x-unsupported then to make it really clear? ;-)
Or simply adopt API guardian here:
https://github.com/eclipse-m2e/m2e-core/discussions/566
> That would be welcome. The issue is that as far as I know,
> there are not so many as convenient tools for good semver
> on package-basis
There is
https://github.com/bndtools/bnd/tree/master/maven/bnd-baseline-maven-plugin
and I created
https://github.com/eclipse/tycho/issues/115
a while back, but as mentioned without a consumer that really likes to
use it it does not makes much sense to improve integration here...
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, or it might
be even valid to configure this once, but I think that makes most sense
if we would deploy every release to maven. Or we would need
https://github.com/eclipse/tycho/issues/590
https://github.com/eclipse/tycho/issues/585
as both would make P2 resolved items available to "pure" maven...
Am 17.02.22 um 11:42 schrieb Mickael Istria:
On Thu, Feb 17, 2022 at 11:33 AM Christoph Läubrich
<laeubi@xxxxxxxxxxxxxx <mailto:laeubi@xxxxxxxxxxxxxx>> wrote:
requiring such a construct is more often an indication that your
API/Bundle is not well shaped. "Internal API" is just the eclipse term
of "its useful but I don't want to maintain backward compatibility
here"
that's a complete different story.
In a well shaped system there is no need for such constructs as
everything that is internal is simply never exported.
IMO, you're in between dogmatism and utopia here ;) And while I have
concerns about dogmatism, I highly respect and envy utopia, it's the
best mindset to make progress.
So at the moment, there is a pragmatic need for those
x-friends/x-internal in m2e (and others). Any change that can be done
towards removing need for that stuff without increasing the amount of
publicly supported APIs and without decreasing the functional value
would be really welcome.
So why not switching then to the more broad adopted terms then? Semver
is not only a matter of package export but also proper version imports
and eclipse is simply not respect that part of semver ..
That would be welcome. The issue is that as far as I know, there are not
so many as convenient tools for good semver on package-basis than there
are for bundle versions so far. At least, definitely not in PDE. Does
BND has such tools? Can they be integrated into a MANIFEST-first workflow?
_______________________________________________
m2e-dev mailing list
m2e-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/m2e-dev
