| Re: [equinox-dev] Marking org.eclipse.osgi.compatibility.state APIs as deprecated? |
_______________________________________________In our age of political extremes, I'm not sure anyone should feel quite so compelled, yet again, to cry out for API-rights activism, to extol its endless and unbounded virtues.
To me it's clear that some of us fail to recognize that the "signal to consumers" may well be that it's time to adopt something other than Eclipse, because no API is actually API, and nothing is actually supported long term. It's all just bathwater (or worse) to be drained whenever it's deemed convenient by those with all the rights. And those with all the rights don't have to care. Not only that, because they don't have to care, they shouldn't care, at least not so much. They should relay their complete (or partial) lack of regard for consumers down the chain so as to spread that disregard as broadly as possible. That makes so much sense! The goodness of that approach to sharing, let's call it 'disregard sharing,' is practically self evident.
I know I don't have to care either and I definitely know I shouldn't care so much. Yet somehow, for some twisted reason, I still do care a lot. Clearly that make me a political extremist; likely even an idiot. But I'm an idiot who has a very hard time listening to an argument that starts with the premise: I don't think 'we' have to care much about 'them'. That's not my Eclipse.
On 08.01.2021 17:50, Mickael Istria wrote:
On Fri, Jan 8, 2021 at 5:32 PM Ed Merks <ed.merks@xxxxxxxxx> wrote:
Thomas,
I think you'll find the use of these APIs have gone far a wide. I count 15 uses of things from this package in my Oomph workspace. Also 804 in my SDK workspace; you'll find them used in PDE and in p2. I don't think anyone understands the implications of removing/changing all these things, I don't think there are "replacements" for them, and even if there are, they're used/surfaced in APIs and I don't think anyone (and most certainly not everyone) has time to rework everything downstream to use replacements and make new APIs...
Although those problems are valid; I don't think Equinox has to care much about them. Equinox (like any project) is free to decide what it maintains or not, and it's usually clearer to state explicitly if something is not expected to be maintained by marking it deprecated than to leave things as if they were maintained and let clients capitalize without warnings on unsustainable code. Clients need to be informed when code they rely on is unmaintained, deprecating is such a hint. Sure, clients will see warnings, but those warnings are meaningful, it's a reminder to them that clients shouldn't expect more maintenance and that they should move away at some point. From there, clients can decide to move away or stick to them according to their own constraints.Even if the API are deprecated now, it doesn't mean that they'll be removed all of a sudden; it's more sending a signal to consumers (p2, Oomph, Tycho...) that adopting newer API becomes more pressing, but it doesn't mean they'll be broken shortly.
_______________________________________________ equinox-dev mailing list equinox-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/equinox-dev
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/equinox-dev