Currently, we build and test against the latest released version of Eclipse, which has some drawbacks:
- If the current Eclipse development breaks an API that we use, we only realize that once that version is released.
- Users might only be able to use the latest LSP4E on the latest version of Eclipse.
See #1512 (comment) or #1428 (comment)
It probably makes sense to build and test against a wider range of versions, similar to what TM4E does.
That is, define an oldest and latest supported version. Then run the build against the oldest version and test against oldest, latest + the current Eclipse staging.
While I'm in favor of supporting a wider range of Eclipse versions, I would prefer only do so to the extent that it does limit the development of LSP4E.
For example, if we say we support at least one year of Eclipse releases, that would also mean that we can only use new Eclipse APIs after they have been released for at least a year.
Opinions?
Currently, we build and test against the latest released version of Eclipse, which has some drawbacks:
See #1512 (comment) or #1428 (comment)
It probably makes sense to build and test against a wider range of versions, similar to what TM4E does.
That is, define an oldest and latest supported version. Then run the build against the oldest version and test against oldest, latest + the current Eclipse staging.
While I'm in favor of supporting a wider range of Eclipse versions, I would prefer only do so to the extent that it does limit the development of LSP4E.
For example, if we say we support at least one year of Eclipse releases, that would also mean that we can only use new Eclipse APIs after they have been released for at least a year.
Opinions?