This has been on the todo list for a while and is required for us to graduate the project.
It was most recently discussed in the mailing list but there have been other discussions such as #537.
The consensus is to formalize something along the lines of:
- Protocol classes and interfaces do not follow API central rules and therefore not (semantic versioning](https://wiki.eclipse.org/Version_Numbering), but instead try to match as closely with the definitions from the DAP and LSP spces.
- Supporting classes (e.g. Launcher, adapters) should follow API rules and semantic versioning
This means consumers of LSP4J will probably want a very tight bound on LSP4J version they use all the time. Therefore, one of the other requirements is that LSP4J must not become a singleton to that in an OSGi environment multiple versions can be imported if needed.
One of the biggest consumers of LSP4J in an OSGi environment is LSP4E which is a singleton bundle.
This issue is to get approval from the community and document the above "formally". The earlier mailing list discussion probably counts as approval already, but please comment anyway.
This has been on the todo list for a while and is required for us to graduate the project.
It was most recently discussed in the mailing list but there have been other discussions such as #537.
The consensus is to formalize something along the lines of:
This means consumers of LSP4J will probably want a very tight bound on LSP4J version they use all the time. Therefore, one of the other requirements is that LSP4J must not become a singleton to that in an OSGi environment multiple versions can be imported if needed.
One of the biggest consumers of LSP4J in an OSGi environment is LSP4E which is a singleton bundle.
This issue is to get approval from the community and document the above "formally". The earlier mailing list discussion probably counts as approval already, but please comment anyway.