Ce n’est pas le développeur des applications qui proposent ce choix (lui il développe, son application c’est celle qui est dans le svn, il s’en tape des versions précédentes — en tant que dév.)
Dans certains cas, les dev. peuvent proposer ce choix. Tous ne sont pas uniquement dans leur svn (ou mercurial, c'est mieux) ... Par exemple des applications comme Firefox ou OpenOffice.org. Ces applications ont un suivi qualité, et si les dev. décident qu'une nouvelle version est stable, on peut leur faire confiance.
L'argumentaire classique revient à faire de l'utilisateur d'une distribution le "client" de cette dernière. Il utilise les applications de la distribution. Sauf que dans certains cas, l'utilisateur final n'a pas forcément ce désir ... et se sent d'avantage "client" du groupe de dev. qui font l'application (Firefox, OpenOffice.org, wine et j'en passe).
Dans ce dernier cas, il n'existe aucun outil pour faciliter le déploiment de telles applications, et on se retrouve très souvent à compiler à la main en outrepassant le système de paquets local (chose que je déteste, le système de paquet est utile dans le mesure où il recense tous les fichiers du système).
ah dans ce cas là je suivais de près les sortis noyaux en outre-passant ma distribution. Il n’y a pas 36 000 solutions si on veut la dernière version d’un logiciel X tout de suite
C'est cela que je regrette, le manque de solutions (techniquement faisable) face à un problème que pas mal de monde s'est posé où se posera au moins un jour dans sa vie de linuxien.
Sauf que pour le moment le public linuxien sait en majorité compiler les applications à la main. Mais il faut penser aux gens qui aiment linux sans forcément savoir compiler (et sans forcément pouvoir apprendre). J'en connais.
[^] # Re: Problème sous linux aussi
Posté par Mildred (site web personnel) . En réponse au journal Maintenez votre Windows à jour.... Évalué à 2.
Dans certains cas, les dev. peuvent proposer ce choix. Tous ne sont pas uniquement dans leur svn (ou mercurial, c'est mieux) ... Par exemple des applications comme Firefox ou OpenOffice.org. Ces applications ont un suivi qualité, et si les dev. décident qu'une nouvelle version est stable, on peut leur faire confiance.
L'argumentaire classique revient à faire de l'utilisateur d'une distribution le "client" de cette dernière. Il utilise les applications de la distribution. Sauf que dans certains cas, l'utilisateur final n'a pas forcément ce désir ... et se sent d'avantage "client" du groupe de dev. qui font l'application (Firefox, OpenOffice.org, wine et j'en passe).
Dans ce dernier cas, il n'existe aucun outil pour faciliter le déploiment de telles applications, et on se retrouve très souvent à compiler à la main en outrepassant le système de paquets local (chose que je déteste, le système de paquet est utile dans le mesure où il recense tous les fichiers du système).
ah dans ce cas là je suivais de près les sortis noyaux en outre-passant ma distribution. Il n’y a pas 36 000 solutions si on veut la dernière version d’un logiciel X tout de suite
C'est cela que je regrette, le manque de solutions (techniquement faisable) face à un problème que pas mal de monde s'est posé où se posera au moins un jour dans sa vie de linuxien.
Sauf que pour le moment le public linuxien sait en majorité compiler les applications à la main. Mais il faut penser aux gens qui aiment linux sans forcément savoir compiler (et sans forcément pouvoir apprendre). J'en connais.