| Hey!
Sorry for being late here.
I am also in favor of keeping the lsp4j API as close to the spec as possible and not worry about backwards compatibility. If additional helper methods and workarounds sum up over time, the API will look quite weird and those compatibility helpers might not even be possible for each and every change.
As a consumer of lsp4j I am happy to adapt to new versions with changed APIs. What I don’t like that much are subtle changes that the compiler doesn’t catch.
This process might require consumers of lsp4j to define upper version bounds to avoid breaking things (in case of OSGi, for example, where you might get a newer version of lsp4j, but still have an older version of lsp4e around, for example).
Just a few thoughts Martin
Hi Jonah,
I’d go for a middle ground:
- LSP / DAP data structures may be subject to breaking changes between minor versions. These changes are documented in the CHANGELOG.
- All other API follows semantic versioning.
Workarounds for protocol changes could accumulate over time and lead to a weird API.
This is not a “strong” opinion — if you prefer another solution, I’m fine with that.
Regards Miro
Hello fellow LSP4J-devs,
I am hoping that this is a topic that someone has already thought of and has a resolution on :-)
Keeping LSP4J up to date with the LSP spec presents some challenges with regards to traditional Java API contracts widely used within Eclipse.
Philip has submitted a fix for LSP4J based on a bug in the LSP spec. The change gives a perfect opportunity to decide how we are going to handle Java API vs LSP spec concerns.
I have made a couple of comments in my review, but I invite suggestions from the community on how we are going to handle this.
e.g. we could:
- Break API in the traditional sense and keep LSP4J as close to LSP spec as possible - Have a fairly strict API breakage policy and changes like the above have to have special "fixes/workarounds" in LSP4J - Have regular major new versions of LSP4J - Something else?
Please share your thoughts - or previous decisions if this has been discussed in the past.
Thanks
Jonah
_______________________________________________ lsp4j-dev mailing list lsp4j-dev@xxxxxxxxxxxTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/lsp4j-dev
-- Dr. Miro Spönemann
Software engineer and consultant
Am Germaniahafen 1, 24143 Kiel
Tel.: +49 151 42679459
Sitz: Kiel, Registergericht: Amtsgericht Kiel, HRB 17385 Geschäftsführer: Sven Efftinge, Moritz Eysholdt, Dr. Jan Köhnlein
_______________________________________________ lsp4j-dev mailing list lsp4j-dev@xxxxxxxxxxxTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/lsp4j-dev
|
