Non. Ubuntu mets tout à jour tous les 6 mois, et en plus il "supporte" sa distrib au moins 18 mois. Voire 5 ans pour Dapper.
Ce qui fait que dans 4 ans, Ubuntu continuera à supporter gcompris 7.2. Mais comme ils n'ont pas l'air de faire grand chose pour le fixer eux-même, et bien pendant 4 ans les utilisateurs de Dapper gardent les mêmes problèmes.
Ce qui gonfle un peu les dev GCompris, comme idée.
Donc, si j'interprète correctement : ce qui "gonfle" les développeurs de GCompris, c'est de devoir supporter les anciennes versions.
Désolé mais dans les véritables environnements, tu auras toujours des utilisateurs qui utiliseront l'ancienne version et à qui la réponse "- faut passer à la dernière version" ne conviendra pas. GCompris est sans aucun doute un cas particulier mais votre mode de fonctionnement désiré ne peut pas s'appliquer à tous les logiciels.
A moins qu'une mise à jour Dapper change la version de GCompris, mais justement non, c'est contraire à la politique. Que des patchs.
Est-ce que cela signifierait que votre développement est incapable de corriger les bogues des versions précédentes en publiant les versions ultérieures ? Je ne crois pas. En outre, il existe tout de même des dépôts de rétro-portage, bien que non disponibles par défaut qui permettent d'avoir les dernières versions, au pire.
Imagine que tous les 6 mois, les apllications utilsateurs de Dapper soient mises à jour (celles qui marchent avec le gtk/qt de dapper). Firefox, GCompris, OpenOffice, Tuxpaint backportés officiellement dans Dapper tous les 6 mois. C'est ça que je voulais dire.
Tous les 6 mois, une nouvelle version de la distribution est publiée. Il suffit simplement pour l'utilisateur de changer de version. Après tout, il n'y a pas que GCompris dans la vie.
Je pense qu'il y a un problème entre votre désir de voir votre logiciel utilisé et testé par des utilisateurs. On en revient à ceci : plutôt que vous dispersez à vouloir que les 200 et quelques distributions soient toutes supportées, il n'y a guère que deux formats binaires importants (Debian et RPM), aussi il ne faut pas non plus trop attendre que quelqu'un d'autre que vous fasse un paquet binaire pour une distribution particulière (notamment FC4 : s'ils ont des problème pour le compiler, ils auront du mal à en produire des paquets).
Par contre, je ne comprends pas ce que tu entends par "Mais attention, c'est à chaque fois des paquets différents. sarge, etch dapper, etch, breezy... et c'est un logiciel connu.". En quoi est-ce des paquets différents ? D'ailleurs, tu as oublié de mentionner cette option : utiliser une source tierce pour disposer de la nouvelle version prévue pour SA distribution et si vous n'êtes pas en mesure pour les produire, il faut bien qu'un "gentil" contributeur s'en charge.
[^] # Re: Utilisation des applications sans 'installation'
Posté par Raphaël SurcouF (site web personnel) . En réponse à la dépêche Amélioration en vue pour l'installation de logiciel sur GNU/Linux.. Évalué à 3.
Donc, si j'interprète correctement : ce qui "gonfle" les développeurs de GCompris, c'est de devoir supporter les anciennes versions.
Désolé mais dans les véritables environnements, tu auras toujours des utilisateurs qui utiliseront l'ancienne version et à qui la réponse "- faut passer à la dernière version" ne conviendra pas. GCompris est sans aucun doute un cas particulier mais votre mode de fonctionnement désiré ne peut pas s'appliquer à tous les logiciels.
Est-ce que cela signifierait que votre développement est incapable de corriger les bogues des versions précédentes en publiant les versions ultérieures ? Je ne crois pas. En outre, il existe tout de même des dépôts de rétro-portage, bien que non disponibles par défaut qui permettent d'avoir les dernières versions, au pire.
Tous les 6 mois, une nouvelle version de la distribution est publiée. Il suffit simplement pour l'utilisateur de changer de version. Après tout, il n'y a pas que GCompris dans la vie.
Je pense qu'il y a un problème entre votre désir de voir votre logiciel utilisé et testé par des utilisateurs. On en revient à ceci : plutôt que vous dispersez à vouloir que les 200 et quelques distributions soient toutes supportées, il n'y a guère que deux formats binaires importants (Debian et RPM), aussi il ne faut pas non plus trop attendre que quelqu'un d'autre que vous fasse un paquet binaire pour une distribution particulière (notamment FC4 : s'ils ont des problème pour le compiler, ils auront du mal à en produire des paquets).
Par contre, je ne comprends pas ce que tu entends par "Mais attention, c'est à chaque fois des paquets différents. sarge, etch dapper, etch, breezy... et c'est un logiciel connu.". En quoi est-ce des paquets différents ? D'ailleurs, tu as oublié de mentionner cette option : utiliser une source tierce pour disposer de la nouvelle version prévue pour SA distribution et si vous n'êtes pas en mesure pour les produire, il faut bien qu'un "gentil" contributeur s'en charge.