>> Ca paraitra peut-etre etonnant a certains, mais dans certaines entreprises, >> on ne peut pas changer les choses comme on veut! La politique a parfois plus >> de poids que la raison technique... :( Donc si la config validee tourne avec >> un 2.0.38, pas question de changer cela d'un iota! >> >> Heureux celui qui peut prendre les _bonnes_ decisions techniques >> librement...
> >�a se justifie parfois. J'ai vu des cas o� changer de version de >compilateur C faisait planter un programme. C'�tait parce que la >vielle version du compilo faisait des initialisations par d�faut de >variables. La nouvelle ne les faisait pas, ce qui est normal. > >Quand on est responsable de la validation, on ne peut pas �tre sur >qu'un changement d'outil n'a aucun impact. Donc si c'est une >application sensible, il faut revalider au moindre changement. J'irais meme plus loin en disant qu'un changement d'outil a forcement un impact, meme s'il est sense avoir une compatibilite ascendante, ne serais-ce que parce que le nouveau code apportera tres vraisemblablement de nouveaux bugs (ce qui pose la question de la pertinence des changements intempestifs de certains elements du kernel linux dans une optique de production). Ce que je disais n'est pas incompatible avec cela, car AMHA des fois ne pas faire evoluer un logiciel ou du hardware est une bonne decision d'un point de vue technique. D'ailleurs, ma remarque s'eloignait un peu du sujet original, et me permettait "d'elargir le debat" en ronchonnant sans vergogne sur des conditions assez souvent rencontre dans ma jeune carriere de "aissessdeuxien" embringue dans la - tristement politique - informatique en milieu bancaire... :-\ A+, Gildas
