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 list [email protected] To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/equinox-dev
