Difference between revisions of "Xtext/Documentation/API"

From Eclipsepedia

Jump to: navigation, search
(Binary but not source compatibility)
(Binary but not source compatibility)
 
Line 1: Line 1:
 
=== Binary but not source compatibility ===
 
=== Binary but not source compatibility ===
  
Xtext versions with minor increments are *binary compatible* with early releases of the same major version
+
Xtext versions with minor increments are '''binary compatible''' with early releases of the same major version
  
That is you will be able to run any code, which was developed *and compiled* against API from 2.x with any 2.y (where y>=x) version. However you might run into compatibility problems  
+
That is you will be able to run any code, which was developed '''and compiled''' against API from 2.x with any 2.y (where y>=x) version. However you might run into compatibility problems  
 
if you try to compile or even regenerate source code which was developed against a previous version, because only micro increments (i.e. 2.x.y -> 2.x.z , where z >= y ) are also guaranteed source compatible.
 
if you try to compile or even regenerate source code which was developed against a previous version, because only micro increments (i.e. 2.x.y -> 2.x.z , where z >= y ) are also guaranteed source compatible.
  
 
Only if the major version increments API might be removed, replaced or changed in *binary incompatible* ways.
 
Only if the major version increments API might be removed, replaced or changed in *binary incompatible* ways.

Latest revision as of 07:11, 30 January 2012

[edit] Binary but not source compatibility

Xtext versions with minor increments are binary compatible with early releases of the same major version

That is you will be able to run any code, which was developed and compiled against API from 2.x with any 2.y (where y>=x) version. However you might run into compatibility problems if you try to compile or even regenerate source code which was developed against a previous version, because only micro increments (i.e. 2.x.y -> 2.x.z , where z >= y ) are also guaranteed source compatible.

Only if the major version increments API might be removed, replaced or changed in *binary incompatible* ways.