Un de mes collègues m'a dit aujourd'hui que certains projets utilisent un bizarre, IMHO, une manière de verrer leurs versions. Si la version est instable, la version mineure est un nombre impair, par exemple. 1.3, 1.5. D'autre part, des versions stables ont un numéro de version uniforme, par exemple. 1.2, 1.4.
Au début, je ne pouvais pas croire mes oreilles, il semblait irréel. Alors Wikipedia m'a éclairé qu'il s'agit d'une pratique provenant de la communauté du noyau Linux, bien que il semble (?) avoir été abandonné récemment.
Quelques heures plus tard, je lis, je lis Programmation de la préface de Ruby , et Qu'est ce que je vois? Ruby utilise la même convention pour les numéros de version.
Quelle est votre expérience avec cela? Quels sont les projets / produits open-source) que vous connaissez qui utilisent ce schéma de version? Existe-t-il un moyen facile de comprendre rapidement s'ils observent cette convention? Est-ce que populaire? J'ai commencé le développement de logiciels il y a un peu plus de 3 ans et n'a pas entendu parler de cette pratique avant.
Merci pour vos réponses.
3 Réponses :
Le noyau Linux a laissé tomber cette pratique avec le début du 26 noyau en 2003 (c'est-à-dire la dernière stable avec une branche de développement 2.5 correspondante). Je viens de regarder ce que j'ai écrit dans mon Maître thèse À propos des projets Généralement:
une scission entre une stable et un
La branche de développement est un très courant
stratégie dans des projets open source,
Bien que certains utilisent plus {note de bas de page}. Les
Les numéros de libération utilisés sont alors également
utilise souvent un schéma impair / pair sur le
former a.b.c où a est une libération majeure
numéro, b est même pour stable et impair
pour le développement et c est une séquence
numéro de libération (parfois un
D supplémentaire est également utilisé).
{Note de bas de page} Par exemple, les xemacs
Le développement est divisé entre trois
Branches: stable, gamma et bêta.
Debian utilise expérimental, instable,
Tests et stables.
Pour plus de détails sur le noyau Linux, n'hésitez pas à lire l'ensemble du chapitre «2.2.4 Linux Development Branches».
EDIT: Le lien d'origine est parti, voici un nouveau lien et une citation appropriée:
Løvdal, H. (2006). Analyse et description d'un concierge de source Open Source
Projet (thèse de maîtrise, Høgskolen i Agder).
Merci hlovdal. Beau sujet pour une thèse principale.
De nombreux projets open source ont utilisé cela, mais la plupart ont changé pour d'autres méthodes. Par exemple, le noyau Linux faisait ceci (il y a tout à fait). Récemment, Mesa (la pile Open Source OpenGL pour Linux) a cessé d'utiliser cette méthode avec la version 2.5.
IMHO, toutes les versions doivent être relativement stables. Si ce n'est pas encore stable, cela devrait être une version alpha ou bêta. Par exemple, la libération KDE 4.0 était une terrible erreur. 4.0 aurait dû être alpha. 4.1 aurait dû être bêta. 4.2 a été la première version vraiment utilisable.
Eh bien, je dirais que pour les projets qui utilisent ce schéma de versions, libérant une version avec un numéro mineur étrange sert le même objectif que l'étiquetage de la libération en version bêta. KDE 4.0 est toutefois une affaire différente car il n'y avait rien dans le numéro de version le marquant comme instable.
@ SEPP2K: tandis que ce schéma de versions a le même but que la bêta, vous ne pouvez pas vous attendre à ce que les utilisateurs sachent cela. De nombreux utilisateurs aiment avoir des logiciels à jour et installeraient (par exemple) CoolNewapp 3.7 sur CoolNewApp 3.6, car il n'est pas immédiatement évident que 3.7 serait instable.
Habituellement, la politique de version de la version pour tout projet donné est bien documentée. De plus, je ne vois pas comment utiliser des lettres grecques est d'une manière ou d'une autre plus intuitive que d'utiliser des chiffres arabes.
GTK + et GNOME utilisent également ce schéma de versions. Notez que Ruby n'utilise plus ce schéma depuis 1,9 (qui est stable).
Merci pour les informations sur Ruby. Apparemment, les gens abandonnent cette convention.
En fait, la raison pour laquelle le schéma de numérotation de la libération de Ruby a été changé, est encore plus obscur: lorsque vous faites une simple chaîne lexicographique comparer, "1.10" trie avant "1,8", il a donc été décidé de libérer quoi aurait été 1.9.x comme 1.9.0-X (par exemple, ce qui aurait été 1.9.2 est devenu 1.9.0-2) et ce qui aurait été 1.10.x comme 1.9.x + 1 (Ainsi, par exemple ce qui aurait été 1.10.1 est devenu 1.9.2). Ainsi, la première version stable de Ruby 1.9 n'était pas Ruby 1.9.0 (publié Noël de 2007) mais Ruby 1.9.1 (publié février 2009).