Handling Backwards Compatibility for Saros/I

[Tobias Bouschen]

Hi all,

As PR #343 [1] shows, there can be changes breaking Intellij backwards
compatibility that are not documented in the list of API changes [2].
This leads to the question on how to best ensure backwards compatibility
through the build server.

To do this, it would be nice to have an automated build on Travis that
still builds against the oldest supported version. On the other hand, we
should also ensure that Saros still works with the newest version of
Intellij, meaning we should also build against this version. This would
mean that we would have to build Saros/I twice. I am not sure if this is
a viable option.

Furthermore, we should discuss what takes precedence when a breaking
change occurs. For #343, the breaking change can easily be avoided by
adding a NOP implementation for the other interface method. But, if
there is no easy fix, how should we proceed?

In my opinion, the newer version of Intellij takes precedence, meaning
we "abandon" support for older, now unsupported, versions of Intellij.

For such a decision, it would be nice to know how frequently developers
update their Intellij version, especially in a company setting, to
ensure that we don't loose to big of a user group when dropping some
backwards compatibility. Since we never released a plugin for IntelliJ,
we don't have any data to pull from. And I am not sure where to get such
information (or if it even exists).

Does anyone else have an opinion on the matter?

Kelvin, do you know if such a double build would be feasible on the
build server and do you have an approximation by how much it would
increase the build time?

Best regards,
Tobias

[1] https://github.com/saros-project/saros/pull/343
[2]
https://www.jetbrains.org/intellij/sdk/docs/reference_guide/api_changes_list.html