Avec RCx à la place des lettres en preprod, c'est encore plus lisible.
Peut-être est-il possible de donner un nom à la version bêta (Ubuntu fait ça) comme on ne sait pas quand elle va sortir ?
Dans le même ordre d'idée, on a le tested/unstable (Sid!) de Debian et les vanilla du noyau Linux. Mais je pense que ce contenter de "RC" est suffisant (surtout qu'on sais bien qu'elle va sortir 2 semaines plus tard si tout ce passe bien)
Peut-être est-il possible de donner un nom à la version bêta (Ubuntu fait ça) comme on ne sait pas quand elle va sortir ?
On peut s'amuser à ça. Vous allez enrichir votre culture si on part là-dessus 
Tiens et pourquoi pas utiliser des nom de fruits comme nom-de-code des releases ? "Zeste de savoir 15.5 - Orange" ou "Zeste de savoir 15.6 - Fraise"
Owi chouette chouette chouette. C'est une super idée ça de donner des noms de code, c'est le truc le plus marrant quand on commence un nouveau projet perso ("Hihi sur quel thème rigolo je vais partir").
Comment j'ai pu passer à côté !!!!
Ça peut être cool en effet :). Dans l'idéal, ça serait bien d'aller piocher dans des agrumes spécifiquement, mais je sais pas combien il y en a x).
Pour aussi les noms de codes. Mais en ordre alphabétique alors.
Mais je pense que ce contenter de "RC" est suffisant (surtout qu'on sais bien qu'elle va sortir 2 semaines plus tard si tout ce passe bien)
Le problème c'est le "si tout se passe bien". Et si la sortie est prévue le 29 et qu'elle a quelques jours de retard, on fait comment ?
Mais je pense que ce contenter de "RC" est suffisant (surtout qu'on sais bien qu'elle va sortir 2 semaines plus tard si tout ce passe bien)
Le problème c'est le "si tout se passe bien". Et si la sortie est prévue le 29 et qu'elle a quelques jours de retard, on fait comment ?
J'essaye de garder le processus simple et d'éviter les débats sur "naaaan, c'est ça le nom de cette version". Mais je suis évidement tout excité à l'idée de donner des noms à nos versions, comme toute personne qui a joué avec Ubuntu dans sa vie, donc j'approuve quand même si vous partez là dedans 
(essayez juste de sortir avec une règle claire qui réduit les futurs débats au minimum, ça serait bête de perdre 15 minutes à chaque fois en Zest'Meeting ou ailleurs pour décider si le nom de notre prochaine version sera "kiwi", "furet" ou "robocop", quoi)
Oh la meilleure règle pour les noms, à mon sens, c'est : "celui qui crée la release choisit".
Oh la meilleure règle pour les noms, à mon sens, c'est : "celui qui crée la release choisit".
Donc toi. Laisse moi deviner, des groupes de rock ?
Ho non, je peux être beaucoup plus varié que ça. Par exemple, au boulot j'ai appelé les interfaces du serveur de stockage "Babar" et "Ganesh" (parce que c'est un gros serveur gris qui a plein de mémoire).
J'suis souvent parti sur "Les protagonistes de la guerre de Troie" perso.
Ça m'est arrivé deux fois, une fois j'ai suivi l'ordre alphabétique et pour l'autre j'ai essayé de m'amuser encore plus, en fonction des améliorations présentes dans la version j'ai cherché le héros le mieux adapté :
etc. etc. Zavez saisi l'idée. C'est très rigolo en tout cas, je vous le conseille (dsl pour le HS)
Perso j'aime pas le système de date, je trouve ca moche et pas si naturel. Ca va bien pour Ubuntu car ils font des releases sur un modèle régulier et ont des LTS, mais pour nous et notre rythme un peu plus aléatoire ça me parait pas propre (on aura pas de joli séquences).
Je préfère nettement le système de version d'Android (peut-être aussi car je travaille avec ?). A savoir majeur.mineur[.paquets-de-correctifs]. Ont a ainsi eu des 1.6, 2.1 - 2.3, 4.1 - 4.4.4 et maintenant 5.0 et 5.1. À chaque version son petit nom facile à retenir et dont la première lettre suit l'alphabet pour faciliter la com' auprès des non-dev (en l’occurrence des noms de dessert/sucrerie en anglais : cupcake, doughnut, eclair…lollipop). Chez Android les changements majeurs sont souvent synonyme de nouveauté dans les guidelines graphiques (et bien sur un paquet de nouveauté invisible concernant plutôt les devs)
Bref, j'aime ce système et j'aime ce que l'on a actuellement. Evidemment c'est un peu plus chiant car il faut définir des règles pour l'évolution des numéros, mais en soit c'est "juste" un numéro. Chez nouson sait que l'incrément symbolise la release et les RC symbolise les corrections de cette dernière. maintenant à voir quand basculer le majeur (huhuhu). Combo, on peut aussi donner un surnom à nos release via une liste de noms de fruits, en ordre alphabetique pour s'y retrouver (abricot, banane, citron…) et si on a vraiment la classe on s'amuse à mettre un petit dessin du fruit de la version en cours dans le design de la page (faudrait un graphiste qui nous les prépare en avance)
J'entends bien, mais le but c'est justement de se débarrasser de la notion de "majeur, mineur, correctifs" qui n'a aucun sens pour nous et qu'on arrive pas à décider de manière logique.
Bah on vire le majeur.mineur et on fait juste un "version[-RC]" ? (même si pour moi par exemple le majeur serait "on pete un module de manière profonde" ou alors "on a un vrai retournement graphique" ou "on a un changement technique profond")
Après je donne juste mon avis hein 
Le simple {version} j'y ai pensé aussi. En fait j'hésite encore. L'avantage de la date, c'est que c'est évident que le numéro de version n'a pas de sens quant au contenu de la version (et c'est précisément l'effet recherché).
Par contre, tout le point depuis le début c'est qu'on est incapable de définir et de se mettre d'accord ce qu'est une version majeure, en plus du fait que le concept de majeure / mineure ne cadre pas avec notre processus de développement.
Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte