La distro peut aussi tout simplement packager la nouvelle version, c'est comme cela que cela fonctionne
dans un monde idéal. Mais un éditeur de logiciel ne va pas attendre 4 ans que la nouvelle Debian sorte, pour avoir le paquet officiel de la dernière version de XulRunner. Et encore, quand une debian sort, bon nombre de paquet ne contiennent pas les dernières releases des libs.
"Bonjour monsieur le client, alors, je vous ai développé votre appli avec XulRunner comme vous le souhaitez, mais il va vous falloir attendre 3 ans ou plus que la prochaine debian stable sorte pour en profiter, parce que la version actuelle de XulRunner est bien trop vieille pour les besoins de l'application."
C'est principalement une conséquence du fait que xulrunner n'est pas pensé comme étant une bibliothèque partagée par plusieurs applications. Du coup ils doivent la modifier.
Non, ils doivent la modifier, parce qu'ils ont des besoins spécifiques que ne fourni pas le XulRunner standards.
Il ne faut pas voir XulRunner comme une lib classique, mais comme une plateforme, un framework embarquable.
Les fonctionnalités spécifiques (comme le support python) pourraient tout à fait être des plugins.
Tout ne peut pas se faire par des plugins. Par exemple, à l'époque où je développais mon éditeur XML wysywyg, j'avais plein de modification dans le coeur du code de l'éditeur de gecko. Impossible d'avoir l'éditeur sous forme de plugin, ça fait parti intégralement du coeur de gecko pour plein de raisons (liés très intimement au moteur de rendu par exemple). Et ce genre de situation arrive souvent dans les projets XulRunner conséquents, que j'ai vu passé.
Pour les patches custom, il suffit d'attendre la release de xulrunner, comme pour toutes les autres bibliothèques sous linux.
Tout les patchs customs ne sont pas forcément utile en upstream car trop spécifiques (c'était le cas de mon éditeur). Donc ça ne sert à rien d'attendre une release de XulRunner.
si Debian package une application, ils se débrouillent pour que les dépendances soient à jour.
Toutes les applications ne sont pas forcément packagées, et encore moins pour toutes les distros ou versions de distros. Donc l'utilisateur devrait utiliser le XulRunner proposé dans sa distro, bien souvent incompatible pour les applis complexes (surtout celles qui contiennent des composants binaires)
Si le patch en lui-même n'est pas intéressant, c'est probablement qu'il faut ajouter un hook au bon endroit, ou que le programme devrait faire autrement.
Oui genre, on peut mettre des hooks partout et puis surtout, en upstream, ils vont accepter ta tonne de patchs insérant des hooks partout… (et je passe sur le coté performance quand il y a des tonnes de hooks)
XulRunner a souvent été utilisé pour des applis innovantes, qui avaient besoin de choses en plus, ou des comportements différents dans le moteur de rendu ou dans des composants.
[^] # Re: à propos de XulRunner
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Une histoire de fork. Évalué à 4.
dans un monde idéal. Mais un éditeur de logiciel ne va pas attendre 4 ans que la nouvelle Debian sorte, pour avoir le paquet officiel de la dernière version de XulRunner. Et encore, quand une debian sort, bon nombre de paquet ne contiennent pas les dernières releases des libs.
"Bonjour monsieur le client, alors, je vous ai développé votre appli avec XulRunner comme vous le souhaitez, mais il va vous falloir attendre 3 ans ou plus que la prochaine debian stable sorte pour en profiter, parce que la version actuelle de XulRunner est bien trop vieille pour les besoins de l'application."
Non, ils doivent la modifier, parce qu'ils ont des besoins spécifiques que ne fourni pas le XulRunner standards.
Il ne faut pas voir XulRunner comme une lib classique, mais comme une plateforme, un framework embarquable.
Tout ne peut pas se faire par des plugins. Par exemple, à l'époque où je développais mon éditeur XML wysywyg, j'avais plein de modification dans le coeur du code de l'éditeur de gecko. Impossible d'avoir l'éditeur sous forme de plugin, ça fait parti intégralement du coeur de gecko pour plein de raisons (liés très intimement au moteur de rendu par exemple). Et ce genre de situation arrive souvent dans les projets XulRunner conséquents, que j'ai vu passé.
Tout les patchs customs ne sont pas forcément utile en upstream car trop spécifiques (c'était le cas de mon éditeur). Donc ça ne sert à rien d'attendre une release de XulRunner.
Toutes les applications ne sont pas forcément packagées, et encore moins pour toutes les distros ou versions de distros. Donc l'utilisateur devrait utiliser le XulRunner proposé dans sa distro, bien souvent incompatible pour les applis complexes (surtout celles qui contiennent des composants binaires)
Oui genre, on peut mettre des hooks partout et puis surtout, en upstream, ils vont accepter ta tonne de patchs insérant des hooks partout… (et je passe sur le coté performance quand il y a des tonnes de hooks)
XulRunner a souvent été utilisé pour des applis innovantes, qui avaient besoin de choses en plus, ou des comportements différents dans le moteur de rendu ou dans des composants.