Linus envisage de changer la numérotation du noyau Linux

Posté par  (site web personnel) . Modéré par patrick_g. Licence CC By‑SA.
Étiquettes :
59
25
mai
2011
Noyau

Linus Torvalds, dictateur bienveillant et grand protecteur du noyau Linux, envisage de mettre à disposition le noyau 2.6.40 sous la dénomination 2.8.0, voire 3.0, comme suggéré par Ingo Molnar.

Depuis la sortie du noyau 2.6.0 en décembre 2003, nous avons pu assister à l’évolution de notre noyau spheniscidé tout au long de ses 40 versions successives. Toute cette évolution s’est faite en suivant un protocole bien rodé, comprenant des cycles de développement de 8 à 12 semaines.

Le cycle de développement commence avec la mise à disposition d’un noyau stable numéroté 2.6.x, suivi d’une fenêtre d’intégration de deux semaines. Cette fenêtre est l’occasion pour les développeurs de proposer tous les patches introduisant de nouvelles fonctionnalités aux différents mainteneurs du noyau.

Ensuite commence la longue route de la stabilisation. Au gré des messages attendus et parfois redoutés de ce pragmatique néo‐Américain qu’est Linus Torvalds, nous voyons apparaître environ 8 versions candidate (RC). À ce stade du développement, n’essayez pas d’introduire la moindre petite fonctionnalité ou le moindre petit pilote, ou il vous en cuira, et chacun pourra suivre sur la liste de diffusion du noyau Linux (LKML) votre admonestation par le sieur Torvalds.

Enfin, lorsque la RC semble suffisamment stable, Linus Torvalds lâche le noyau 2.6.(x + 1) dans la nature, et un nouveau cycle peut recommencer.

Mais cette fois, quelque chose de différent risque d’arriver : le nouveau noyau passera à la version 2.8 ou 3.0 ! Concrètement, quelle est la raison de ce changement de numérotation ? Quelles nouvelles fonctionnalités révolutionnaires, quel changement d’API et quelle grande réécriture du code entraîne ce passage à une version 2.8 ? Rien. Linus nous fait juste savoir dans un post scriptum, que des voix dans sa tête lui ont dit que 40, c’est grand, et donc qu’il faut passer à une version supérieure.

Néanmoins, il ne faut pas s’y tromper. Le mode de développement du noyau, qui se fait de manière progressive, pas après pas, a engendré des changements énormes depuis la 2.6.0. Donc, même si ce noyau s’inscrira dans la continuité du 2.6.39, ça permettra sans doute aussi de satisfaire notre besoin de discriminer de grandes étapes du développement linuxien, et de pouvoir s’asseoir devant son PC d’ici quelques mois en se disant « Ouah, j’utilise la nouvelle génération de noyaux Linux ! ». Et rien que ça ravira les geeks du monde entier au plus profond de leur cerveau reptilien.

Aller plus loin

  • # Comme Google Chrome en fait

    Posté par  . Évalué à 10.

    Je trouve cette nouvelle mode (faire grossir les numéros de versions de façon drastique) complètement ridicule. Après Google Chrome et Mozzarella Firefox, voilà que le kernel s'y met aussi !

    En guise de protestation, je vais passer à Hurd.

    • [^] # Re: Comme Google Chrome en fait

      Posté par  . Évalué à 9.

      C'est vrai que le Hurd ça fait vingt ans que le numéro de version n'a pas augmenté, et c'est parti pour continuer encore un moment !

    • [^] # Re: Comme Google Chrome en fait

      Posté par  (site web personnel) . Évalué à 10.

      En fait la justification de Linus, si on oublie la plaisanterie initiale sur le mode du "j'ai entendu des voix dans ma tête", c'est de dire que le passage dans la troisième décennie d'existence du noyau serait une bonne occasion de basculer vers la version 3.0.

      C'est une raison qui en vaut une autre et c'est vrai que ce serait pas mal de simplifier un peu la numérotation. Les 3.x seraient les nouvelles versions habituelles qui sortent tous les 2 ou 3 mois et les 3.x.x seraient les correctifs des diverses branches stables.

      Mais enfin bon il ne faut pas oublier qu'à ce stade rien n'a été vraiment décidé. Wait and see.

      • [^] # Re: Comme Google Chrome en fait

        Posté par  (site web personnel) . Évalué à 10.

        Un autre point essentiel, cité sur la LKML, c'est le fait que de très nombreuses entreprises font du support pour linux 2.6, alors que leur expertise s’arrête parfois au 2.6.9. Vu le rythme effréné du développement du noyau, dire que l'on connaît ou supporte linux 2.6 devient de moins en moins clair.

        Je suis personnellement pour un passage direct au 3.0 car ça n'a plus de sens de trimballer un numéro de version à 3 ou 4 nombres s'il n'y a plus de branche instable.

    • [^] # Re: Comme Google Chrome en fait

      Posté par  (Mastodon) . Évalué à 10.

      Après 20 ans, être encore à 2.X, c'est quand même pas l'inflation folle !

      Il y a assez peu de logiciel qui peuvent en dire autant... Apache (httpd) qui en est à 2.3 (en version bêta) né en 1995, GNOME 3.0 né en 1999. On pourrait aussi inclure Java qui en est à la (vraie) version (pas commerciale) 1.6 né en 1995. D'autres idées ?

      • [^] # Re: Comme Google Chrome en fait

        Posté par  . Évalué à 10.

        • TeX version 3.1415926 (né en 1977).
        • Latex version 2ε (né en 1985). (Latex3 en projet depuis 1994).
        • glibc 2.13 (versions préliminaires en 1988, version 0.1 en 1991)
        • « INIT: version 2.86 booting »

    • [^] # Re: Comme Google Chrome en fait

      Posté par  (site web personnel) . Évalué à 5.

      Je suis d'accord avec toi sur l'incrémentation du numéro de version de cette manière. Je suis même déçu de l'utilisation de cette « nouvelle » numérotation pour Firefox.

      Mais, ici, il n'est pas question d'entrer dans cette mode. Depuis le début de la version 2.6, il y a eu 40 versions avec des changements plus ou moins important. Passer à la 2.8 est une forme de confirmation de tout ces changements.

      Une fois à la 2.8, ils repartiront sur du 2.8.x.

      Au finale, c'est sur, ce ne sont que des chiffres.

    • [^] # Re: Comme Google Chrome en fait

      Posté par  (site web personnel) . Évalué à 10.

      J'ai pas l'impression que ce soit la même chose.
      Firefox ou chrome n'ont au final qu'un numéro de version public (4, 5, 10, 11, ...) car au final le public n'en a rien à carré de la signification d'un numéro de version, la seule chose qui compte en fait est que ce soit la version suivante.

      Pour linux, j'y vois deux choses :

      • si ça passe à 3, ça passerait à 3.0 et non 3.0.0, et donc on oublie le dernier nombre de maintenance, on en profite donc pour simplifier la numérotation

      So I'm toying with 3.0 (and in that case, it really would be "3.0",
      not "3.0.0" - the stable team would get the third digit rather than
      the fourth one.

      • c'est juste de la numérotation, avoir un kernel 2.6.40 qui de toute façon n'a rien à voir avec un kernel 2.6.4 est totalement ridicule, on perd dans ce cas l'intérêt d'avoir un sens à la numérotation (supermajeur.majeur.mineur.release ?)

      Dans le cas présent, le numéro ne monterait pas de manière drastique mais rétabli juste un peu les numéros qui à l'heure actuelle sont presque ridicules et ne veulent pas dire grand chose. Surtout dans le cas d'un passage au 2.8.

      Maintenant, la différence par rapport au mode de développement précédent, est qu'on est dans un vrai développement incrémental où on ne casse rien de violent en une fois, mais un peu tout le temps, et c'est à la vue des changements effectués tout au long de la vie du 2.6 un succès. Et dans ce type de développement avoir des numérotations type x.y.z(.w) devient ridicule car ne se raccrochent à rien de vraiment concret.

      D'ailleurs, sur les version de chrome, le document https://docs.google.com/present/view?id=dg63dpc6_4d7vkk6ch&pli=1 est assez intéressant. Et j'ai l'impression que beaucoup de logiciels vont dans ce sens (non pas que ce soit chrome qui ait instauré quoi que ce soit, mais juste que c'est une bonne façon de faire à mon avis.

      • [^] # Re: Comme Google Chrome en fait

        Posté par  . Évalué à 2.

        Et donc supposons que le système actuel, qui marche très bien soit-dit en passant, arrive à une certaine limite, à partir de laquelle on constate un besoin de créer une branche expérimentale pour casser un truc vraiment trop fort en profondeur.

        On rechange le numéro de version? On met quoi ce coup-ci? Linux 4? Linux 10 pour bien marquer que c'est un changement vraiment important? Linux 2012? Linux 3000? Linux XP/Vista/Seven?

        C'est vrai que la numérotation actuelle n'a plus de sens. Pourquoi ne pas faire comme enlightenment? La version en cours est la 0.17.
        Cette numérotation est absurde au vu de l'avancement du projet, donc en pratique, c'est E17 ou DR17.
        Pour ceux qui n'aiment pas les nombres, on n'a qu'à avoir un L40, L41, L42.

        En plus, ça évitera (comme je l'ai dit sur le journal) de se retrouver avec des bugs de parsing de numéro de version...

        • [^] # Re: Comme Google Chrome en fait

          Posté par  (site web personnel) . Évalué à 9.

          hum, plusieurs choses à mon avis

          Déjà, si le besoin est "juste" d'avoir une branche pour casser un truc, pas besoin de changer de version, git, branch, un nom est c'est réglé, il y a un espace pour bosser avant de merger.

          Maintenant, oui, pourquoi dans ce cas ne pas passer à linux 4 si on est déjà au 3 ? (et m'étonnerais qu'on ait un linux 2.10 si jamais on avait un 2.8)

          En fait, j'ai du mal à comprendre cet attachement à des nombres qui ne veulent rien dire ? Ou plutôt, il ne faut pas accorder plus d'importance à ces nombres que leur sens.
          Donc si par exemple le BKL (comme supposé par certains) instaure un changement suffisamment important, pourquoi ne pas passer à la version 3 ? Et si un autre changement apparaît alors qu'on est au 3.20.x alors pourquoi ça ne deviendrait pas le 4 ?
          Au final on dirait une sorte de "peur" pour certains que les numéros de version se "commercialisent" alors que je trouve plutôt pour ma part que ça devient bien plus clair. Par exemple un 3.20.2 dirait simplement 2° release (de maintenance) du 20° kernel de la branche 3.
          Le 20 n'ayant pas plus de sens que 20°.

          D'ailleurs il y a déjà eu un changement important par le passé. Initialement le kernel, sous la forme x.y signifiait y% de la version x. On voit bien ce que ça à donné avec un 0.99 patch level 15Z... N'arrivant pas suffisamment bien à estimer ce qu'il reste / manque, il me paraît beaucoup plus logique de voir ça purement incrémental et donc d'avoir un <branche>.<incrément>.<fix release>, c'est au final plus clair qu'un y qui de toute façon ne correspond pas réellement à l'avancée.

    • [^] # Re: Comme Google Chrome en fait

      Posté par  . Évalué à 1.

      je suis du même avis.

      que ce soit 2.6.40 ou 2.8.0 ou 3.0.0 R.A.F. ce qui compte, c'est le bon fonctionnement du produit....

      • [^] # Re: Comme Google Chrome en fait

        Posté par  . Évalué à 10.

        Ou alors après avoir vu Squeeze sortir cette année et très bientôt Duke Forever, Linus s'est dit qu'il était temps pour lui de lacher le 2.6 avant que Hurd ne le coiffe au poteau...

    • [^] # Re: Comme Google Chrome en fait

      Posté par  . Évalué à 4.

      J'aime bien le principe chez OpenBSD :
      .

      y étant compris entre 0 et 9.
      Quand y et à 9 on incremente x et y revient 0.

      Simple, efficace, on ne se pose pas la question "est ce que c'est une release majeure ?"

    • [^] # Re: Comme Google Chrome en fait

      Posté par  . Évalué à 5.

      Et comme éditeur de texte disponible sous Hurd, tu as GNU Emacs version 23.3/24.1.

    • [^] # Re: Comme Google Chrome en fait

      Posté par  (site web personnel) . Évalué à 7.

      Après Linux 3.0, je propose Linux XP et Linux Vista. On alors des noms de félins (par exemple Linux Matou).

    • [^] # Re: Comme Google Chrome en fait

      Posté par  . Évalué à 1.

      C'est vrai. Le changement c'est le mal. Les gens sont habitué à cette numérotation, c'est là une raison suffisante pour la conserver, les numéros de version c'est pas que des chiffres, c'est bien mieux si ils ont un sens (ça donne à peu de frais des information sur le logiciel dont on parle).

      Please do not feed the trolls

    • [^] # Re: Comme Google Chrome en fait

      Posté par  (site web personnel) . Évalué à 4.

      En guise de protestation, je vais passer à Hurd.

      Et installer Window Maker :)

  • # Spirituel

    Posté par  . Évalué à 4.

    when the voices tell me to do things, I listen

    écrit Linus.

    On pourrait parler de spiritualisation du développement du noyau.

  • # la réponse à la question ...

    Posté par  (site web personnel) . Évalué à 10.

    Moi j'attendrais bien encore 3 versions :)

  • # Si proche

    Posté par  . Évalué à 10.

    En ce jour saint de Towel Day je suis attristé de s'arrêter si proche du 2.6.42!

  • # Mauvaise idée.

    Posté par  . Évalué à 6.

    C'est pas comme ça qu'on dépassera Windev, ils en sont à la version 16 (et en multiplateforme, eux).

    • [^] # Re: Mauvaise idée.

      Posté par  . Évalué à 4.

      On est que mercredi, c'est pas le bon jour pour attaquer le manque de portabilité du noyau Linux...
      Ou alors tu veux un OS "multiplateformes", mais là je ne vois pas ce que c'est.

      • [^] # Re: Mauvaise idée.

        Posté par  (site web personnel) . Évalué à 10.

        Emacs ?

        • [^] # Re: Mauvaise idée.

          Posté par  (site web personnel) . Évalué à 3.

          dans ce cas, emacs fonctionnant dans jslinux dans firefox sous linux dans qemu s'exécutant sous linux
          Et hop, on a 4 OS et 2 mastodontes (ni linux, ni jslinux ni qemu n'en étant, saura tu trouver les deux ?)

      • [^] # Re: Mauvaise idée.

        Posté par  (site web personnel, Mastodon) . Évalué à 1.

        Mais Linux est multi-plateforme : il fonctionne très bien sur de nombreuses architectures matérielles.

        Second degré ? Où ?!! Où ?!!

      • [^] # Re: Mauvaise idée.

        Posté par  (site web personnel) . Évalué à 10.

        Ou alors tu veux un OS "multiplateformes", mais là je ne vois pas ce que c'est.

        Mais oui, la voilà l'idée du siècle ! Un OS compatible MSDOS, Windows, Macintosh et Linux qui supporterait la domotique, l'intelligence artificielle, ne pouvant être contaminé par des virus informatique, transportable, ne craignant pas le piratage informatique si utilisé sans autre OS !

        GNU's Not Unix / LINUX Is Not Unix Xernel

  • # BKL

    Posté par  (site web personnel) . Évalué à 6.

    La fin du Big Kernel Lock peut être une bonne occasion. On a quelques releases 2.6.x sans BKL, on voit que ça marche bien, la 2.8 peut refléter ce grand changement.

    Et c'est vrai qu'entre la 2.6.1 et 2.6.38, il y a une sacré évolution.
    Donc pourquoi pas.

    • [^] # Re: BKL

      Posté par  . Évalué à -2.

      Du point vu professionnel, avec un changement de version majeur, on s'attend à une incompatibilité majeur, du à un changement de certaines API. Le BKL surtout dans les dernières releases n'a été fait que pour le cosmétique.

      Personnellement, je suis contre le changement de version majeur, si c'est uniquement justifié que parce que 40 commence à faire un nombre élevé!

      Pour exemple pour java, on est rendu à 1.6 update 25 (on parle de la version 1.7, mais la date de release n'est pas encore connu).

      • [^] # Re: BKL

        Posté par  (site web personnel) . Évalué à 7.

        Du point vu professionnel, avec un changement de version majeur, on s'attend à une incompatibilité majeur

        Ben justement, c'est fort : "hey les pros, zavaient vu ça on change de numéro majeur sans rien casser. C'est fini ce troll maintenant ?" C'est très fort de changer de numéro majeur sans rien casser justement ;-)

        Le BKL surtout dans les dernières releases n'a été fait que pour le cosmétique.

        Pas cosmétique : symbolique.
        Avant de pouvoir retirer cette option il a fallut un immense nettoyage de code sur tout ce qui demandait le giant lock. La disparition de cette option marque donc, réellement, la fin d'une grande étape.

      • [^] # Re: BKL

        Posté par  . Évalué à 2.

        Pour exemple pour java, on est rendu à 1.6 update 25 (on parle de la version 1.7, mais la date de release n'est pas encore connu).

        Sauf que ça n'a rien à voir, les 25 updates de Java, ce n'est que des corrections de bugs, il n'y a pas de fonctionnalités différentes, contrairement à aux 40 version de Linux 2.6.

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: BKL

          Posté par  . Évalué à 1.

          les 25 updates de Java, ce n'est que des corrections de bugs

          Tu devrais regarder les changelog, par exemple dans le 1.6.0_25 (le premier fait par oracle, tiens donc...) ils ont introduit une mise à jour de hotspot qui casse certains des outils (non supportés il est vrai) fournis en standard avec le JDK.
          cf http://www.oracle.com/technetwork/java/javase/6u25releasenotes-356444.html
          (et ce n'était pas la première fois dans la série 1.6.0 qu'ils mettaient hotspot à jour)

          Autre exemple, dans la 1.6.0_10
          http://www.oracle.com/technetwork/java/javase/6u10-142936.html
          ils ont mis à jour java DB (qui n'est qu'une version repackagée d'apache derby) en version 10.4 alors que la 1.6.0 originale avait une version 10.2.
          Cette _10 introduisait aussi une nouvelle implémentation du plugin java.

          • [^] # Re: BKL

            Posté par  . Évalué à 3.

            D'accord, c'est plus que des corrections de bug, mais ça n'a rien à voir avec le changelog de Linux en 2.6.0 et 2.6.39

            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: BKL

        Posté par  (site web personnel) . Évalué à 1.

        C'est pas si facile de marcher dans celui-là. Bien fait, dans la tradition, joli !

    • [^] # Re: BKL

      Posté par  (site web personnel) . Évalué à 1.

      Et puis il y a d'autres bonnes occasions : la fin de unix ... gnu is definitly not unix :p (bon, à part osX) Le Linux-centrisme qui voit le jour dans les systèmes, donc dans certaines distributions. Le succès mondial de Android, présent et à venir. Les vingts ans du noyau. Il y en plein, finalement, des raisons d'un changement de version ;) Certaines incontestables, plus ou moins aimables, d'autres trolliphères. Bref : plein :-)

  • # BKL

    Posté par  . Évalué à 10.

    Hello,

    Si je ne m'abuse, le passage à la version 2 de notre cher noyau marqua son entrée dans le monde du SMP, avec l'utilisation du fameux (fumeux ?) Big Kernel Lock.
    Pour moi, la disparition du BKL me paraît être un événement d'une ampleur suffisante pour marquer le passage à la version 3.0. Maintenant Linux partie fait des systèmes permettant réellement une montée en charge satisfaisante sur des gros systèmes.

    François.

  • # et bzip3 ?

    Posté par  (site web personnel) . Évalué à 10.

    Linux 3 ne peut pas sortir, bzip3 ne l'est pas non plus !

    ipot screen

    Au passage, pour ceux qui pensent que c'est trop tôt pour un Linux 3.0.0, on voit qu'en 2001, un Linux 3.2.24 en 2006 était une prévision tout à fait réaliste (à la différence d'IPoT :p), à l'époque le noyau était encore en 2.4, et pas depuis très longtemps.

    ce commentaire est sous licence cc by 4 et précédentes

    • [^] # Re: et bzip3 ?

      Posté par  . Évalué à 5.

      Normal, tu as mal initialisé IPoT ;).

      # cat 1 > ipot
cat: 1: No such file or directory

      Tu voulais probablement faire:

      # echo 1 > ipot

    • [^] # Re: et bzip3 ?

      Posté par  . Évalué à -3.

      Mmh, relis ton xterm. La prochaine fois, préserve un peu mieux ta vie privée.

      • [^] # Re: et bzip3 ?

        Posté par  . Évalué à 1.

        Bon j'arrête le coup de stress, y a pas de mplayer teletubbies.avi. :D

      • [^] # Re: et bzip3 ?

        Posté par  . Évalué à 3.

        C'est pas lui qui a fait le screenshot.

        En plus, à l'époque, Facebook était encore en mode démarrage, donc il n'y avait aucun problème de vie privée!

        Hein? Comment ça j'ai rien pigé??

        ------------>[ ]

  • # Pourquoi garder des chiffres si ils ne servent à rien.

    Posté par  (site web personnel) . Évalué à 9.

    Pour moi un numéro de version doit avoir une signification. Exemple Qt: X.Y.Z
    toutes les versions de la série X sont rétrocompatible binaire et Y marque l'évolution de l'API (nouvelles features), Z les corrections de bugs (pas de changements d'API).

    Je trouve ça ridicule des projets qui gardent un chiffre inutile ou qui sera incrementé dans 30 ans:
    gstreamer -> 0.10.32 (pas de compatibilité binaire entre 0.8 et 0.10). Pourquoi pas simplement virer ce 0 qui sert à rien: gstreamer 10.32
    inkscape 0.48.1 idem: inkscape 48.1

    C'est quoi exactement le problème d'avoir un numéro principal qui grossit ?

    Il me semble que dans le noyau, il n'y a pas vraiment de notion de retro-compatibilité, l'API est suceptible d'être cassée à n'importe quel moment, le 2.6 n'a donc pas de signification particulière. Ca vous choque tellement de dire linux 38 au lieu de linux 2.6.38

  • # 666

    Posté par  . Évalué à 7.

    J'espérais qu'on arriverait à linux-2.6.66

    • [^] # Re: 666

      Posté par  . Évalué à 6.

      Non, le satanisme c'est déjà pris par FreeBSD comme thème..

  • # Et le BKL

    Posté par  . Évalué à 1.

    Est-ce que la suppression BKL n'est pas une évolution suffisante pour passer à une nouvelle version majeure ?

    • [^] # Re: Et le BKL

      Posté par  (Mastodon) . Évalué à 4.

      Je dirais même plus : la suppression du BKL est une évolution suffisante pour passer à une nouvelle version majeure !

  • # 2.6.40

    Posté par  . Évalué à 1.

    Moi j'aime bien le numéro de version actuel, je vois pas trop l'intérêt de changer subitement, sans raisons apparentes.

    Enfin bon, si finalement le numéro de version change, je continuerais à utiliser Linux quand même :-)

    • [^] # Re: 2.6.40

      Posté par  . Évalué à 2.

      Bah c'est justement ça le problème, depuis le changement de mode de développement, les numéros 2.6 n'ont plus de raison de changer !

      Donc soit on reste éternellement en 2.6.XX soit on change de méthode de numérotation pour recréer des repères.

      • [^] # Re: 2.6.40

        Posté par  . Évalué à 0.

        Si, les numéros de tête continuent de changer régulièrement:
        2.0, 2.2, 2.4, 2.4, 2.6.16, 2.6.27, 2.6.32, …

        • [^] # Re: 2.6.40

          Posté par  . Évalué à 2.

          Parce-qu'il y avait une version de développement dont l'aboutissement des objectifs + stabilisation constituais la version n+1.

          Ça fait déjà quelques années que Linux n'utilise en fait qu'un chiffre de pertinent (x.x.39), bon, certains logiciels le font ( Udev 168) mais ce n'est pas adapté au noyau, imaginons que ce mode de numérotation ai été choisi dès le début de développement du noyau :

          Linux a intégré depuis la versions 100 un système de routeur/firewall, il s'agit d'abords d'ipfwadm disponible jusqu'à la version 201, il a été cependant remplacé dans la version 199 par ipchains lui-même remplacé à partir de la version 504 par netfilter, ipchains est cependant resté disponible jusqu'à la version 763...

          Compliqué non ? Un numéro de versions en majeur.mineur permet dans le cas du noyau d'avoir des repères temporel clair et de savoir immédiatement à peu près les technologies mises en oeuvres, repères actuellement perdus !

          • [^] # Re: 2.6.40

            Posté par  . Évalué à 1.

            Ça me fait mal d'expliquer un troll… le mien sous-entendait que mainline est le noyau de développement et que les vraies versions stables ce sont 2.4, 2.6.16, 2.6.27, etc.

  • # Schéma basé sur le temps

    Posté par  (site web personnel) . Évalué à 10.

    Moi j'aime bien la propal de Boaz sur LKML

    En tenant compte du fait que les versions sont toujours stables et que c'est le temps qui fait grossir les numéros de version, Boaz propose le schéma suivant

    D . A . N

    D : décade depuis la naissance (soit 3e depuis 1991)
    A : année dans la décade ( 3.1.x 3.2.x, ... 3.10.x, 4.1.x, ...)
    N : Nième lâcher de noyau par Linus dans l'année

    Avec ça on peut :
    * Garder les 3 digits pour la compatibilité des scripts
    * Se rendre compte de la date de sortie en lisant le numéro de version
    * Avoir une "jolie" progression avec des numéro de version qui plairont aux admins

    Sympa, non ?

    • [^] # Re: Schéma basé sur le temps

      Posté par  . Évalué à 4.

      D : décade depuis la naissance (soit 3e depuis 1991)

      Dans ce cas, autant utiliser la véritable origine des temps, qui est comme on le sait bien le 1er janvier 1970 à minuit. Comme ça les dates de sortie seront encore plus lisibles.

    • [^] # Re: Schéma basé sur le temps

      Posté par  . Évalué à 7.

      J'ai eu l'occasion d'utiliser ce type de numérotation. Les problèmes commencent quand tu te retrouves à livrer en retard par rapport à ton planning, ou pour les versions qui sont à cheval sur deux périodes.

      Tu démarres la 3.2.11 (11ième "lâché" de noyau de l'année 2 de la 3ième décade) en prévoyant de la livrer le 21/12/2012. Et paf, tu la livres 32 ans après (le temps que l'apocalypse se soit tassée, et que les arbres aient repoussé). Et paf, ton numéro devient incompréhensible.

      Les geeks qui étaient restés planqués chez eux pendant que la croûte terrestre se stabilisait vont basculer sur BSD.

    • [^] # Re: Schéma basé sur le temps

      Posté par  (site web personnel) . Évalué à 10.

      D : décade depuis la naissance (soit 3e depuis 1991)

      Il y a eu environ 730 décades depuis 1991. Je suppose que tu veux parler de décennies.

    • [^] # Re: Schéma basé sur le temps

      Posté par  (site web personnel) . Évalué à 2.

      Sympa, non ?

      Je ne vois pas à quoi ça sert.

      Avec le schéma classique tu détermines facilement de deux versions quelle est la plus récente. De plus, les changements de version t'informent sur les changements d'interface: c'est une information plus intéressante que celle de sortie de la release.

      La correspondance entre versions et dates de release est affichée sur la page d'accueil de kernel.org, c'est donc une information facilement accessible.

      • [^] # Re: Schéma basé sur le temps

        Posté par  (site web personnel) . Évalué à 0.

        Avec le schéma classique tu détermines facilement de deux versions quelle est la plus récente.

        Ce serait toujours le cas.

        De plus, les changements de version t'informent sur les changements d'interface: c'est une information plus intéressante que celle de sortie de la release.

        Pour le noyau, les changements d'interface se font dans la douceur, petit à petit. Il serait intéressant d'énumérer le nombre de syscall modifiés/ajouté sur la série 2.6. Un gars disait qu'il y avait plus de similitudes entre un 2.4.x et un 2.6.1 qu'entre un 2.6.9 et un 2.6.37.

    • [^] # Re: Schéma basé sur le temps

      Posté par  . Évalué à 4.

      Et si on se calait sur les releases d'Ubuntu ?

      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

  • # Le choix fixé

    Posté par  . Évalué à 3.

    Et bien, on peut dire que Linus a tranché :

    mainline: 3.0-rc1 2011-05-30 [Gitweb]

    source: http://kernel.org/

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.