Contents Up Previous Next

Compatibilité descendante

Bon nombre des interfaces utilisateur et des plateformes supportées par wxWidgets sont en constante évolution, et certaines des nouvelles plateformes que wxWidgets supporte désormais étaient inimaginables il y a seulement quelques années. Dans ce contexte, wxWidgets doit également évoluer afin de supporter ces nouvelles plateformes et fonctionnalités.

Toutefois, l'objectif de wxWidgets n'est pas seulement de fournir une interface de programmation à travers de nombreuses plateformes, mais aussi de fournir une interface qui est raisonablement stable dans le temps, afin d'aider à la protection de ses utilisateurs face aux incertitudes du futur.

Le schéma de numérotation des versions
Niveau de compatibilité source
Compatibilité binaire de la bibliothèque
Compatibilité binaire de l'application


Le schéma de numérotation des versions

Les numéros de version de wxWidgets peuvent avoir jusqu'à quatre composants, les zéros finaux étant parfois omis:

    majeur.mineur.release.sous-release
Une release stable de wxWidgets aura un chiffre mineur pair, par exemple 2.6.0.

Stable, dans ce contexte, signifie que l'API ne change pas. En vérité, certains changements sont permis, mais seulement ceux qui sont rétrocompatibles. Par exemple, vous pouvez attendre des releases suivant 2.6.x.x, telles que 2.6.1 et 2.6.2 qu'elles soient rétrocompatibles avec leurs précédentes.

Quand il devient nécessaire de faire des changements quine sont pas complêtement rétrocompatibles, la branche stable est dupliquée, créant une nouvelle branche développement de wxWidgets. Cette branche développement aura un chiffre mineur impair, par exemple 2.7.x.x. Les releases de cette branche sont appelées instantanés de développement.

La branche stable et la branche développement seront alors développées en parallèle pendant un temps. Quand il devient inutile de continuer à développer la branche stable, la branche développement est renommées et devient une nouvelle branche stable, par exemple 2.8.0. Et le processus recommence.

C'est ainsi qu'est gérée la tension entre garder une interface stable et permettre à la bibliothèque d'évoluer.

Vous pouvez attendre de versions ayant les mêmes numéros majeurs et mineurs pairs à ce qu'elles soient compatibles, mais entre les numéros de versions mineurs, il y aura des incompatibilités. La compatibilité n'est toutefois pas cassée gratuitement, ainsi, bon nombre d'applications ne demanderont aucun changement ou seulement de petits changements pour fonctionner avec la nouvelle version.


Niveau de compatibilité source

Les releases suivantes d'une branche stable sont rétrocompatibles avec les releases précédentes de cette branche stable au niveau source.

Cela signifie que, par exemple, si vous développez votre application en utilisant wxWidgets 2.6.0 alors, il sera possible de la compiler correctement avec toutes les versions 2.6.x suivantes. L'inverse est également vrai, si vous évitez d'utiliser les nouvelles fonctionnalités non présentes dans la version précédente. Par exemple, si vous développez en utilisant 2.6.1, votre programme pourra être compilé avec wxWidgets 2.6.0 à la condition que vous n'utilisiez pas les fonctionnalités spécifiques à la version 2.6.1.

Pour certaines plateformes, la compatibilité binaire est également supportée, voyez 'Compatibilité binaire de la bibliothèque' ci-dessous.

Entre les versions mineures, par exemple, entre 2.2.x, 2.4.x et 2.6.x, il y aura des incompatibilités. Dans la mesure du possible, une ancienne façon de faire quelque chose est conservée parallèlement à la nouvelle pendant un certain temps, encapsulé dans :

    #if WXWIN_COMPATIBILITY_2_4
        /* fonctionnalité dépréciée */
        ...
    #endif
Par défaut, la macro WXWIN_COMPATIBILITY_X_X est mise à 1 pour la branche stable précédente, par exemple, dans la version 2.6.x WXWIN_COMPATIBILITY_2_4 = 1. Pour la prochaine branche stable, la valeur sera 0 par défaut, ainsi, WXWIN_COMPATIBILITY_2_2 = 0 pour 2.6.x. Les fonctionnalités obsolètes antérieures sont supprimées.

Ces macros peuvent être changées dans setup.h. Ou, sur un système apparenté à Unix, vous pouvez les définir en utilisant les options --disable-compat24 et --enable-compat22 avec configure.

Elles peuvent être utiles dans deux cas:

  1. Mettre WXWIN_COMPATIBILITY_2_4 à 0 peut être utile pour trouver l'utilisation de fonctionnalités dépréciées dans votre programme.
  2. Mettre WXWIN_COMPATIBILITY_2_2 à 1 peut être utile pour compiler un programme développé avec 2.2.x alors qu'il n'est plus compilable avec 2.6.x.

Un programme nécessitant que l'une de ces macros soit mise à 1 deviendra incompatible avec les futures versions de wxWidgets, et vous devrez penser à le mettre à jour.


Compatibilité binaire de la bibliothèque

Pour certaines plateformes, les releases d'une branche stable ne sont pas compatibles uniquement au niveau source, mais elles peuvent également être compatible binairement.

La compatibilité binaire rend possible l'obtention du maximum de bénéfices lors de l'utilisation des bibliothèques partagées, également connues comme bibliothèques liées dynamiquement (Dlls) sous Windows, ou bibliothèques partagées dynamiques sous OS X.

Par exemple, supposons que plusieurs applcations sont installées sur un système, et qu'elles nécessittent wxWidgets 2.6.0, 2.6.1 et 2.6.2. Comme 2.6.2 est rétrocompatible avec les versions précédentes, il n'est nécessaire d'installer que les bibliothèques wxWidgets 2.6.2 partagées, et toutes les applications seront aptes à les utiliser. Si la compatibilité binaire n'était pas supportée, alors, toutes les versions recquises 2.6.0, 2.6.1 et 2.6.2 devraient être installées conjointement.

Section non traduite: Achieving this, without the user being required to have the source code and recompile everything, places many extra constraints on the changes that can be made within the stable branch. So it is not supported for all platforms, and not for all versions of wxWidgets. To date it has mainly been supported by wxGTK for UNIX-like platforms.

Une autre considération pratique est que, pour que la compatibilité binaire puisse marcher, toutes les applications et bibliothèques doivent avoir été compilées avec des compilateurs capables de produire du code compatible, c'est à dire qu'ils doivent utiliser la même ABI (Application Binary Interface). Malheureusement, la majorité des différents compilateurs C++ ne produisent pas de code compatible les uns avec les autres, et bien souvent, différentes versions d'un même compilateur ne sont pas compatibles.


Compatibilité binaire de l'application

L'aspect le plus important le la compatibilité binaire est que les applications compilés avec une version de wxWidgets, par exemple, 2.6.1, continueront de fonctionner avec des bibliothèques partagées d'une version compatible suivante, par exemple 2.6.2.

L'inverse peut cependant aussi être utile. En d'autres termes, il peut être utile pour un développeur utilisant une version plus récente, par exemple 2.6.2, d'être en mesure de créer des paquetages d'applications binaires qui fonctionneront avec toutes les versions binairement compatibles de la bibliothèque partagée avec, par exemple, 2.6.0.

Pour ce faire, le développeur doit bien entendu éviter toute fonctionnalité non disponible dans les précédentes versions. Toutefois, ce n'est pas nécessairement suffisant; dans certains cas, une application compilée avec une dernière version peut en dépendre même malgré le fait que le même code serait compilable correctement avec une ancienne version. Pour cela, une directive du préprocesseur wxABI_VERSION peut être définie durant la compilation de l'application (cela est généralement fait dans le makefile ou dans les options du projet). Elle doit être réglée au plus bas numéro de version auquel elle est destinée, comme un nombre avec deux chiffres pour chaque composant par exemple wxABI_VERSION=20600 pour 2.6.0.

Définir wxABI_VERSION devrait empêcher l'application d'explicitement dépendre d'une dernière version de wxWidgets, et désactive également toute nouvelle fonctionnalité dans l'API, offrant une vérification au moment de la compilation que le code source est compatible avec les versions de wxWidgets prises pour cible.

Les utilisations de wxABI_VERSION sont supprimées des sources wxWidgets quand chaque nouvelle branche de développement est créée. Par conséquent, cette directive est seulement utile pour aider à assurer la compatibilité avec les versions ayant les mêmes numéros de version majeurs et mineurs pair. Elle ne vous aidera pas, par exemple, à écrire du code compatible avec 2.4.x en utilisant wxWidgets 2.6.x.