Bonjour,
 
Il me semble que pour les logiciels il y a des règles à respecter pour numéroter
les versions.
Comme par exemple x.y.z pour des résolutions de petits bugs ou x.y pour des
modifications notables, il me semble que un nombre paire ou impaire signifie
une version stable ou non, enfin je ne sais pas trop comment cela fonctionne.
Mais si il y a des règles bien définit, quelqu'un  pourrais il me les éxpliquer
 
merci

En fait, c'est chacun qui fait sa norme mais il y a quand même quelques régles habituellements respecté (mais pas toujours):

• dans l'ordre RC, R , alpha, beta, stable : ca indique l'avancement de la version, "RC", c'est la premiére version publique, "R", c'est les versions stabilisés au niveau développement (on ne rajoutera pas de nouvelles options ou capacités) alpha, c'est pour les versions, dont la stabilité est plus qu'asardeuse ou inconus, beta, c'est pour les versions buggué mais considéré comme utilisable, stable, c'est les versions qui sont censé n'avoir quasiment plus aucun bug. En pratique, ce n'est que dans les trés gros projets qu'on voit des RC et dans les gros projets qu'on a droit à des R.
• x.y.z.b le b, c'est le numéro de build de la version courante. En gros, à chaque recompilation du logiciel, c'est censé augmenter de 1. le z, c'est pour les suimple correction de bugs. Le y c'est pour les changements visible ou important. Le x c'est pour les changements les plus importants.
• yyyymmddhhmmss : La date et l'heure de la compilation.

Certains rajoutent même le nom de la machine servant à compiler le programme et plus rarement une indication permettant de savoir si c'est une version contenant les infos de debug ou pas.
 
Pour le nombre pair ou impair, c'est juste un choix fait par ceux qui s'occupent de certains projets tels que linux. On trouve plus souvent la notation x.6 à 9 pour les versions de développement et x.0 à 5 pour les versions stables.
 
Il est possible de n'utiliser qu'une seule de ces notation ou plusieurs.

ca se sont des règles principalement utilisées dans le monde OSS: x.y.z pour les versions majeures, mineures et les sous versions (principalement des bugfixes). Certains logiciels et projets (comme le kernel linux) utilisent en plus une distinction paires/impaires pour les branches stables ou instables (pour le kernel Linux, le seul nombre dans lequel paire/impaire a une signification est la révision majeure), d'autres ne font pas cette distinction.
 
Depuis le 2.6.11, le kernel est même en x.y.z.t, avec "t" pour les bugfixes et les patchs de sécurité, z étant les révisions mineures, y les révisions majeures et x les versions du kernel.
 
Le versioning du kernel
les différents schémas de versioning courament rencontrés

ok et bien merci beaucoup, toutes les infos que je cherchais, merci beaucoup, c'est pour mon projet car j'avais un peu l'impression de noter un peu n'importe comment les versions

sans compter ceux qui suivent un versionning bidon, comme le fait de se baser sur un nombre connu (nombre d'or, PI, e, etc...) et d'ajouter une décimale à chaque version
j'ai pas d'exemples pour le nombre d'or (mais ca doit se trouver), par contre le soft le plus célèbre utilisant PI est TeX....la première version a été 3, puis 3.1, puis 3.14, etc...
 
mais ce sont des schémas de versionning farfelu

Dans ma boite, nous numérotons comme suit :
 
9.99A
 
Explication :
En cas de correction de bug, la lettre augmente (A ==> B, B==> C...)
En cas d'amélioration mineure, nous augmentons les unités des décimales.
En cas d'amélioration majeure, nous augmentons les dizaines des décimales.
En cas de refonte du programme, nous renumérotons le premier 9 (partie entière)...