Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

Compatibility is a complex issue, but we do our best in maintaining three types of compatibilities between two sequential versions of SSLR ( e.g. between 1.17 and 1.18, but not between 1.16 and 1.18 ):

  • binary compatibility: we don't guarantee that your code can be linked with new version without recompilation, however for most releases this might be possible;
  • source compatibility: in most cases (see below) you should be able to recompile your code with newer version of SSLR without any changes;
  • behavioral compatibility: in most cases (see below) your code will behave exactly as with previous version of SSLR without any changes.

We can't guarantee that your code can be compiled or linked with new version of SSLR and will behave exactly as before upgrade in following situations:

  • You use internal classes or interfaces, i.e. those that are located under package "org.sonar.sslr.internal".
  • You create instances or subclasses of classes, which are not intended for this. Such classes are marked by Javadoc ("This class is not intended to be instantiated or sub-classed by clients").
  • You implement interfaces, which are not intended for this. Such interfaces are marked by Javadoc ("This interface is not intended to be implemented by clients").
  • You use methods marked as internal. Such methods are marked by annotation "@VisibleForTesting" or by Javadoc ("For internal use only").
  • You use deprecated code. Such code is marked by annotation "@deprecated" and Javadoc.

Thus it's highly recommended to not jump over two versions at once, but perform upgrades in several steps - by one version per step. And such step should include removal of uses of deprecated code.

  • No labels