• [^] # Re: Impossible

    Posté par (site web personnel, Mastodon) . En réponse à la dépêche Le mkframework, découvrez un framework php très différent. Évalué à 5.

    Les systèmes de modules (avec leurs propres vues, contrôleurs et cie...) dans les frameworks, ça ne date pas de ZF, Sf ou même de mk. Jelix le fait depuis 2006 (qui est un fork de Copix qui le faisait déjà en 2004). Et possible qu'on puisse en trouver d'autres avant 2009...

    et puis un framework qui garde de la retrocompatibilité aussi longtemps que mkframework, ça me laisse songeur.

    • soit c'est un framework qui n'évolue pas (en terme d'API et d'organisation), et donc que son auteur n'évolue pas dans sa manière de coder ou ne tient pas compte des problèmes rapportés par ses utilisateurs (ne vient pas me dire que l'API parfaite existe)
    • soit c'est un framework qui est très minimaliste. Mais alors les utilisateurs auront tout de même des problèmes de rétrocompatibilités avec l'utilisation de lib externes. Et probablement aussi qu'ils n'utiliseront ce fmk que pour les petits projets.
    • soit c'est un framework qui maintient N version de la même API, mais cela veut dire très certainement de plus en plus de code mort à chaque nouvelle version (celui qui utilise une version d'une API, n'utilise pas les autres forcément). Et le code mort, c'est mal (contributions compliquées si pas bien documenté, code parsé pour rien par PHP, ou fichiers inutiles etc...).

    Il faut trouver un juste milieu quand on maintient une lib ou un framework. Les usages, les technologies, les besoins évoluent au fil du temps, et donc forcément, les APIs. Et il faut de temps en temps virer les vieux trucs, faire le ménage.

    Alors j'aimerais bien comprendre dans quel cas tu te situe parmi ceux que je viens d'évoquer, ou alors comment arrives-tu à garder cette rétrocompatibilité aussi longtemps ?

    Sur Jelix, j'ai fait des compromis :

    • les versions (1.0, 1.1, 1.2....) sont maintenues pendant 3 ans environ (aboutissant à des releases 1.0.1, 1.0.2 ...) : uniquement des corrections de bugs et de trous de sécu. Mais pas de changements d'API (sauf si vraiment la correction d'un bug majeur l'oblige mais ça n'est pas arrivé en 9 ans ou je ne m'en souviens pas).
    • Une version peut faire évoluer une API. Déjà, très important, cette modification est documentée dans la documentation de migration (exemple), en plus des nouveautés (exemple). Si il s'agit de paramètres supplémentaires, j'essaye de faire en sorte que ce soit des paramètres optionnels. Ou alors je créé une nouvelle méthode ou classe et je marque l'ancienne "déprécié" quand cela reste pertinent. L'API dépréciée ne disparait du code source qu'au cours des futures version. Cela laisse le temps de migrer vers la nouvelle API.
    • Pour une version majeure (de 1.x à 2.x) : je me laisse la liberté de casser les API (c'est ce qui se passe pour la future 2.x, après 9 ans de dev sur la 1.x). Il faut savoir un jour faire table rase sur certains aspects, et arrêter de se trainer des boulets (qui n'en étaient pas forcément à l'époque où ils ont été développé). Un code "moderne", une API moderne, ça attire plus les utilisateurs (et les contributeurs). Et puis ça fait du bien pour les nouveaux projets.