Ed I feel your response is an indictment of anyone who ever made a bad (design) decision and later tries to correct it. But that's what API changes are!
At some point something has to give. If you ever wish to improve things you have to at some point deprecate the old stuff. That's just evolution. It's sad but it's necessary. Furthermore, "high degree of change" I'd argue is NOT one of the things that we're seeing causing migration away from Eclipse. it's rather the contrary. People are willing to adopt ENTIRELY new solutions in order to get new features. That's worse in my mind than too much change. My 2 cents, - Ray On Fri, Jan 8, 2021 at 1:18 PM Ed Merks <[email protected]> wrote: > 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 <[email protected]> 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 [email protected] > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/equinox-dev > > _______________________________________________ > equinox-dev mailing list > [email protected] > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/equinox-dev > -- *Raymond Augé* (@rotty3000) Senior Software Architect *Liferay, Inc.* (@Liferay) OSGi Fellow
_______________________________________________ equinox-dev mailing list [email protected] To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/equinox-dev
