Jump to: navigation, search

Difference between revisions of "Xtext/Documentation/API"

(Binary but not source Compatibility)
(Binary but not source compatibility)
Line 4: Line 4:
  
 
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 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.

Revision as of 06:05, 30 January 2012

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.