API et ABI

La compatibilité entre deux versions de VLE dépend de deux paramètres que sont l'API et l'ABI.

API & ABI
Ces deux éléments font partis de tout projet informatique et particulièrement pour les projets informatiques utilisant des ressources compilées sur le système d'exploitation, par exemple des bibliothèques de fonctions.

API
API, application programming interface, est le code source qui fait l'interface entre une bibliothèque ou un système d'exploitation et les codes sources clients, par exemples d'autres bibliothèques ou des programmes.

Par exemple, le fichier stdio.h est une API que vous pouvez utiliser depuis des codes sources C. De la même manière, le fichier vle/devs/Dynamics.hpp est une API que vous pouvez utiliser pour développer des modèles.

ABI
ABI, application binary interface, décris le code bas-niveau (code compilé) qui fait le lien entre une bibliothèques ou un système d'exploitation est les codes sources clients, par exemples d'autres bibliothèques ou des programmes.

Par exemple, le fichier libvledevs.so sous GNU/Linux ou libvledevs.dll sous Windows représente l'ABI que vous utilisez lorsque vous exécutez une simulation avec VLE.

Casser l'API
Casser l'API est simplement le fait de venir modifier des structures, classes, fonctions des fichiers de l'API. Ainsi, modifier le code suivant casse l'API :

Casser l'ABI
Casser l'ABI consiste simplement modifier la structure binaire bas-niveau du objet compiler. Toute modification de l'API touche profondément l'ABI. Par exemple :

Mais pas uniquement, les modifications de tailles entre variables, casse la compatibilité alors que la compilation passera sans problème. Par exemple :

Pourquoi VLE n'assure pas de compatibilité ascendante API/ABI ?

 * oblige à polluer le code source de VLE avec des structures de maintient de compatibilité.
 * nécessite trop de temps.
 * le code source est le meilleur moyen de partage de modèles.

Ce que nous assurons
Les versions d'une même branche (Cf. Feuille de route), par exemple les version 0.5.0, 0.5.1 etc. seront compatibles en terme d'API et d'ABI dans la mesure du possible. Ainsi, un modèle compilé pour la version 0.5.0 sera compatible avec la version 0.5.1 etc. c'est-à-dire, pour l'ensemble de la branche 0.5.x.

En ce qui concerne les modèles écrits pour la version 0.5.x, leurs fonctionnement dans la version 0.6.x ne sera pas assuré même si nous essayons de limiter les modifications de l'API et de l'ABI mais en aucun cas, nous ne pourrons assurer cette compatibilité.