Je vois pas très bien d'où tu tires l'information que ça marchait pas du tout pour Linux et très bien pour Gnome. Ce dont je suis sûr, c'est que les release impaires de Linux sont bien plus testées en terme de nombre d'utilisateurs que celles de Gnome (sans méchanceté, mais juste parce que Linux a une base d'utilisateurs supérieure).
Quant à ton serpent qui se mord la queue, tous les projets logiciels ont ce problème, que la version en cours de test soit appelée alpha, beta, 2.5, unstable, preview release ou autre, elle est toujours insuffisamment testée du goûts de développeurs. Je ne vois pas en quoi Gnome s'en sort mieux que n'importe quel autre projet sur ce plan.
Chez GNOME, ça ne change rien : on sait que ça sort tous les 6 mois.
Euh, donc tu penses que faire des release "time-based" est une justification pour utiliser la numérotation actuelle de Gnome. Tu peux détailler tes arguments ?
De nouvelles releases mineures sont faites après la sortie officielle pour corriger les plus gros bugs passés à travers des mailles du filet lors de la validation de la version de développement.
Oui, comme pour à peu près 95% des projets logiciels.
Du coup les versions x.y avec y impair servent juste de convention pour les alpha/beta/rc de la version x.(y+1),
Donc ça, je pense que j'avais compris.
et ont l'avantage de permettre une comparaison numérique (pas de alpha/beta/rc dans le nom de la version)
Bon, c'est un bon argument, mais orienté vraiment très très développeur. Et des projets qui utilisent le vocable alpha / beta / rc / preview arrivent quand même à faire des numérotations de versions qui se comparent numériquement.
On peut donc indiquer que telle fonction est obsolète depuis GTK 3.3.90, ce qui est plus précis pendant le cycle de développement que de dire que c'est obsolète depuis GTK 3.4.0.
Euh, tu veux dire que 3.4.0 , c'est moins précis que 3.3.90 ? De quel point de vue ?
Bon, c'est une petite pique cette histoire de version. Mais autant je comprends que des vieux projets comme apache ou samba utilisent encore cette façon de faire (ah tiens non, samba a arrêté depuis longtemps il semblerait), autant pour un projet qui se veut aussi moderne et dans le vent que Gnome, je trouve ça ridicule.
[^] # Re: Et pour la numérotation de versions
Posté par Philippe F (site web personnel) . En réponse à la dépêche GNOME 3.4 : l'émergence des applications. Évalué à 3.
Je vois pas très bien d'où tu tires l'information que ça marchait pas du tout pour Linux et très bien pour Gnome. Ce dont je suis sûr, c'est que les release impaires de Linux sont bien plus testées en terme de nombre d'utilisateurs que celles de Gnome (sans méchanceté, mais juste parce que Linux a une base d'utilisateurs supérieure).
Quant à ton serpent qui se mord la queue, tous les projets logiciels ont ce problème, que la version en cours de test soit appelée alpha, beta, 2.5, unstable, preview release ou autre, elle est toujours insuffisamment testée du goûts de développeurs. Je ne vois pas en quoi Gnome s'en sort mieux que n'importe quel autre projet sur ce plan.
Euh, donc tu penses que faire des release "time-based" est une justification pour utiliser la numérotation actuelle de Gnome. Tu peux détailler tes arguments ?
Oui, comme pour à peu près 95% des projets logiciels.
Donc ça, je pense que j'avais compris.
Bon, c'est un bon argument, mais orienté vraiment très très développeur. Et des projets qui utilisent le vocable alpha / beta / rc / preview arrivent quand même à faire des numérotations de versions qui se comparent numériquement.
Euh, tu veux dire que 3.4.0 , c'est moins précis que 3.3.90 ? De quel point de vue ?
Bon, c'est une petite pique cette histoire de version. Mais autant je comprends que des vieux projets comme apache ou samba utilisent encore cette façon de faire (ah tiens non, samba a arrêté depuis longtemps il semblerait), autant pour un projet qui se veut aussi moderne et dans le vent que Gnome, je trouve ça ridicule.