• Auteur : Chagab
  • Date : 22 mars 2004 (6 janvier 2005)
  • Licence : Creative Commons BY-NC-ND link_license

Les noms d’applications

Entre « RC » (Release Candidate), version « bêta » , Versions noyau paires, impaires etc. Pourquoi ces dénominations complexes et comment s’y retrouver...

Il y a quelques années (entre 15 et 20 selon ma mémoire !), même dans les entreprises et projets sérieux, il n’était pas rare que, lors de la correction d’un bogue, en phase de tests (ou lors de la mise en production) on en retrouvait un, corrigé antérieurement. Parfois même, on mettait en évidence la perte d’une fonctionnalité qui venait d’être implémentée par une intervention antérieure. De plus la complexité des produits créés allant croissante, les fameux tests (bête noire des informaticiens) devenaient de plus en plus difficiles à réaliser. C’était le royaume de la régression fonctionnelle et de la réapparition des erreurs corrigées.

D’aucuns (je ne sais pas dire qui ! quand j’écris ce type d’article, je me rends compte de l’étendue de mes méconnaissances... ;-) ) ont donc utilisé un truc pour s’y retrouver : Ils associaient au Nom du Projet un GOROCO (ou un de ses acolytes « bêta tests », voire « Release Candidate », ...).

Le GOROCO [1]

Dans la dénomination des « objets » informatiques divers et variés, nécessaires à la construction d’un logiciel (catalogues, fichiers, programmes, modules, ...), l’ensemble des possibilités de « nommage » offertes par le GOROCO est ou n’est pas utilisé en fonction de l’intérêt de le faire ou en fonction des habitudes du projet. Les lettres G, R, C peuvent être remplacées par des points ou des blancs mais alors les chiffres sont « positionnels » et leur signification est G,R,C.

  • G (et donc le 1er chiffre) voulant dire Génération,
  • R (et donc le second) Révision,
  • C (le troisième) Correction.

Pour comprendre : un exemple

Dans Linux Planète (dont je ne saurais que recommander la lecture !) de décembre 2003, j’ai lu que Linus Torvalds (le leader du noyau Linux) a décidé de nommer le prochain noyau « 2.6 » (c’est à dire « sixième Révision » de la « Génération 2 » du noyau Linux) et non « 3 » car il estime que la compatibilité des API [2] restant la même sur ce noyau, celui-ci est considéré comme un progrès justifiant une révision (la sixième) mais reste dans la continuité (de la seconde Génération du noyau).

Ce Kernel sorti en janvier, s’appelle donc 2.6-test9. Il est directement issu de la 2.5.75 (G2R5C75, vous avez tout compris !). Il attend ses testeurs (vous et moi, pourquoi pas !) avant d’être déclaré complètement « stable » après correction des divers bogues restants...

Normalement, et c’est typique de Linux, seuls les noyaux à « R » pair (4.2, 4.4) sont considérés comme stables et donc utilisables en exploitation. Les noyaux à « R » impair étant considérés comme en phase de développement (4.1, 4.3, ...).

Les versions à « R » impair, sont par ailleurs appelés version « bêta », c’est à dire en cours de test et donc : non exploitables . Les Releases Candidates peuvent donc être assimilées à des versions à « R » pair mais en version test (à l’instar du noyau 2.6-test9 en janvier).

On s’y retrouve donc. On parle de la même chose en termes parfois légèrement différents.

Article polémique s’il en est... Je tends le dos, allez-y de vos commentaires. Mon but est simple : tenter d’expliquer cette méthode de traçage des interventions sur les logiciels à des débutants qui ne l’utiliseront pas dans leur usage courant mais veulent seulement comprendre le pourquoi des choses.

Patrick Cegielski dans "Conception de systèmes d’exploitation : Le cas Linux" chez EYROLLES (non conseillé à un débutant Linux, mais un bijou pour les spécialistes du domaine informatique qui veulent comprendre Linux et au passage approfondir leurs connaissances sur les systèmes d’exploitation...) dit sur ce sujet :

“Chaque version est caractérisée par trois nombres entiers séparés par des points. Les deux premiers identifient la version, le troisième la parution (release en anglais).

Un second numéro pair identifie un noyau stable ; impair, il dénote un noyau en développement. Les nouvelles parutions d’une version stable visent essentiellement à corriger des erreurs signalées par les utilisateurs ; les algorithmes principaux et les structures de données du noyau ne sont pas modifiées.

Les versions en développement, en revanche, peuvent différer les unes des autres de façon importante. Les développeurs du noyau libre sont libres d’expérimenter différentes solutions qui peuvent éventuellement conduire à des changements drastiques du noyau.”

A la relecture du passage de ce livre, je me demande pourquoi j’ai passé autant de temps à écrire cet article ? ;-)

[1] GOROCO :

Le GOROCO a été mis en place dans mon entreprise dans le milieu des années 80. Il a permis d’importants progrès dans la gestion des versions applicatives. Même s’il est à la marge de ce qui existe sous Linux, je prends cet exemple car il explique bien ce que l’on a voulu faire et le résultat obtenu. C’est quoi ? C’est simplement un ensemble de lettres et de chiffres permettant de savoir à quelle version appartiennentt un module, un programme, voire une abrorescence de stockage de source ou de binaires.

[2] API :

Application Programming Interface : Interface de programmation d’application. Manière de séparer la gestion des contraintes physiques liées à la machine (par exemple : comment sont écrits les blocs sur les disques, taille de blocs, nombres, ... comment sont contrôlées leur écriture, ...) des besoins des programmeurs (écrire un ensemble d’informations sur disque), le programmeur délégant donc à l’API la gestion de toutes les contraintes matérielles.

Commentaires

<< Poster un message >>
:: question :: précision :: avis :: commentaire :: bug ::

Les noms d’applications , le 28 décembre 2005 par ETOGA MALA (0 rép.)

s’lut je vous écrits car j’aimerais avoir des infrormations sur tout ce qui concerne les logiciels d’applications. écrivez moi vite s’il vous plait, je meur d’envie d’avoir ces infos. merci d’avance

-----> les noms d’applications

Répondre à ce message

> Les noms d’applications : Je ferai pareil ! , le 18 septembre 2005 par Domsau2 (0 rép.)

Bonjour.

Je suivrai cette nomenclature, dès maintenant !

Merci pour ces explications.

Répondre à ce message

y a til d autre site en francais et anglais ?? , le 15 juillet 2004 (2 rép.)

j aimerais approfondir le sujet

> y a til d autre site en francais et anglais ?? , le 15 juillet 2004 par ChaGab

Ce système d’identification et de différentiation des "objets" créés marche à peu près avec tout. Les programmes, les arborescences de stockage des softs créés (source, objets) mais aussi au niveau des versions en production.

On peut aussi appliquer la méthode aux productions documentaires à leurs versions successives (on parle alors non pas de GOROCO mais de SOFO -mais désolé, je ne me rappelle plus de ce que cela veut dire-)...

J’ai fait cet article de synthèse parce que cela m’amusait d’expliciter la méthode que j’ai utilisée (et que j’utilise encore quand ça en vaut la peine). Des sites traitant de ce sujet, il y en a peut-être, certainement d’ailleurs, mais je n’en connais pas. Le Cegielski donné en référence, est cité in extenso...

Maintenant, à vous de mettre en oeuvre et de trouver la méthode d’identification de ce que vous produisez adaptée à votre problème. Il faut cependant savoir que cette méthode de travail nécessite une rigueur de mise en oeuvre extrêment contraignante. Tout ça ne fonctionne que dans ce cadre.

Si par contre, vous m’expliquez votre problème, je peux essayer de vous aider pour mettre en oeuvre la solution la plus efficace pour vous. Cordialement

> y a til d autre site en francais et anglais ?? , le 19 septembre 2004 par Vent d’Est

Merci de votre réponse et article , que j’ apprecie particulierement .Effectivement La structure GOROCO est très intérressante pour d’une part mieux appréhender la logique d’évolution des softs ,permettant de comprendre ce qu’on utilise en quelques nombres :) et quoi s’en tenir :) (comme une synthèse , ou une sorte de carte ) et aussi de se prémunir contre la logique marketing de certains softs qui utilise les nombres pour montrer leurs supériorités .. (genre un passage de 8 à 9 sans grands changements , mais juste quelques patchs ... )

je me demandais aussi quel autre type de structures , on peut utilisé pour montrer les évolutions d’une’ entité ’ (soft , doc , images ... )

L’idéal ce serait de tombé sur un site qui parles que de ca et comparant les avantages inconvénnient des différents modèles , permettant ainsi de choisir le plus appropriés .

Vent d’est :liu.qihao(at)gmail.com

le (at) c est contre les robots a l’affut d adresse pour le spam a remplacé par le petit arobase

Répondre à ce message

Informations complémentaires

Faire un don ? (défiscalisé)

Faire un DON

Aidez-nous à atteindre notre objectif de 800 donateurs récurrents pour assurer notre pérennité et notre développement ! (nous n’y sommes plus très loin).

Je soutiens Framasoft pour 10€/mois

Informations générales

Juste une image

piazza della cancelleria houses, lomo version piazza della cancelleria houses, lomo version
Creative Commons BY