I have an Eclipse plugin that can also expose a LSP server, implemented with lsp4e.
You mean the language server is implemented with LSP4J (which had API changes) and consumed in the IDE by LSP4E (which didn't have much API change from consumer POV) ?
If it's LSP4J, then I *think* (not sure) that the bundles are not singleton. So in the IDE, if you separate your server from the client integration properly, then you can probably have the server using an older version of LSP4J and the client with LSP4E using the newer one.
However, with the API changes/breakage in the 2020-03 version of lsp4e I see no easy way to create a plugin that uses lsp4e while still being useable in both Eclipse 2020-03 and in older versions (at least 2019-12 but preferably even older versions).
Which specific API change in *LSP4E* are you affected by?
For other Eclipse components I have come to expect that old APIs do not break in new releases so I am hoping that I am missing something obvious.
No, LSP4J and LSP4E don't (yet) ensure backward compatibility of APIs.
Actually, for LSP4E, most of the exported packages are not to be considered API.
Ideally I would want to develop in the latest Eclipse IDE (2020-03) and continue to build a single plugin (with Tycho) in a way that is compatible with both older and newer versions of Eclipse.
See above, if the issue is LSP4J and LSP4J is not a singleton, a good separation of server and client with a strict version range management in the Require-Bundle directive can allow to use different versions of LSP4J and avoid broken APIs.
