> Rien à voir avec des crashes. On parle de fonctionnalités ici. Les
> crashes se sont des bugs rien à voir avec un upgrade majeur. Une
> correction de bug c'est un upgrade mineur.
Bah à lire ça, j'espère que tu n'es pas mainteneur d'un soft que
j'utilise. Bon, alors on va faire un petit cours de fiabilité des
logiciels ...
Quand tu fais une upgrade majeure, tu changes du code. Il y a un truc
qui dit qu'un bon développeur, après avoir testé un minimum son
logiciel, laisse environ 5 bugs par 1000 lignes de code. Si tu changes
un million de lignes de code, il faut donc t'attendre à avoir environ
5000 nouveaux bugs, et d'un autre côté, les changements que tu as fait
(souvent des réécritures completes de certains morceaux) t'ont éliminé
un grand nombre de bugs. Bref, entre la version majeure N et la
version N+1, les bugs ne sont pas les mêmes.
Dans tous les cas, sauf utilisation de méthodes formelles, ou petit
bout de code relativement trivial, il y aura des bugs. Il y a
des milliers de bugs dans Windows, des milliers de bugs dans
Debian, ... le truc étant que les milliers de bugs qui restent après
le test, ce sont ceux qui se voient le moins, sinon, on les aurait
corrigé.
Maintenant, tu développes une application par dessus ces milliers de
bugs. Si tu as vraiment de la chance, tu ne tombera sur aucun de ces
bugs, mais peut-être que tu n'auras pas cette chance sur la version
N+1. Si t'as un peu moins de chance, tu tombes sur un bug, et tu
trouves un moyen de le contourner, et là non plus, tu ne sais pas si
ce contournement sera encore valable dans la version suivante. Et si
tu n'as vraiment pas de chance, le bon fonctionnement de ton
application peut dépendre d'un bug, et là, si le bug est corrigé,
c'est le drame (j'avais entendu dire que Windows émulait parfois des
bugs des versions précédantes pour que des applications continuent à
fonctionner).
Si tu n'as pas encore entendu parler d'une application sous Linux qui
cesse de fonctionner à cause d'une upgrade du noyau, de la libc, ou
autre composant du système, je te suggère 1) de te renseigner un peu
2) d'arrêter de donner des leçons.
Allez, quelques exemples :
Combien d'applications développées il y a quelques années ne compilent
même plus sur un GCC récent ?
Combien de fois une décision technique dans le noyau a cassé
cdrecord ?
Alors bien sur, quand les logiciels sont dans la distribution, on
corrige les incompatibilités et la version stable suivante est
cohérente (c'est précisément un des gros avantages du libre), mais il
faut se faire à l'idée que sous la plupart des distributions, si tu
achètes un logiciel externe pour la version N, tu n'as aucune garantie
qu'il continue à marcher après une upgrade du système.
[^] # Re: ah merde alors
Posté par Matthieu Moy (site web personnel) . En réponse au journal Debian ne supportera plus la Woody à la fin du mois. Évalué à 2.
> crashes se sont des bugs rien à voir avec un upgrade majeur. Une
> correction de bug c'est un upgrade mineur.
Bah à lire ça, j'espère que tu n'es pas mainteneur d'un soft que
j'utilise. Bon, alors on va faire un petit cours de fiabilité des
logiciels ...
Quand tu fais une upgrade majeure, tu changes du code. Il y a un truc
qui dit qu'un bon développeur, après avoir testé un minimum son
logiciel, laisse environ 5 bugs par 1000 lignes de code. Si tu changes
un million de lignes de code, il faut donc t'attendre à avoir environ
5000 nouveaux bugs, et d'un autre côté, les changements que tu as fait
(souvent des réécritures completes de certains morceaux) t'ont éliminé
un grand nombre de bugs. Bref, entre la version majeure N et la
version N+1, les bugs ne sont pas les mêmes.
Dans tous les cas, sauf utilisation de méthodes formelles, ou petit
bout de code relativement trivial, il y aura des bugs. Il y a
des milliers de bugs dans Windows, des milliers de bugs dans
Debian, ... le truc étant que les milliers de bugs qui restent après
le test, ce sont ceux qui se voient le moins, sinon, on les aurait
corrigé.
Maintenant, tu développes une application par dessus ces milliers de
bugs. Si tu as vraiment de la chance, tu ne tombera sur aucun de ces
bugs, mais peut-être que tu n'auras pas cette chance sur la version
N+1. Si t'as un peu moins de chance, tu tombes sur un bug, et tu
trouves un moyen de le contourner, et là non plus, tu ne sais pas si
ce contournement sera encore valable dans la version suivante. Et si
tu n'as vraiment pas de chance, le bon fonctionnement de ton
application peut dépendre d'un bug, et là, si le bug est corrigé,
c'est le drame (j'avais entendu dire que Windows émulait parfois des
bugs des versions précédantes pour que des applications continuent à
fonctionner).
Si tu n'as pas encore entendu parler d'une application sous Linux qui
cesse de fonctionner à cause d'une upgrade du noyau, de la libc, ou
autre composant du système, je te suggère 1) de te renseigner un peu
2) d'arrêter de donner des leçons.
Allez, quelques exemples :
Combien d'applications développées il y a quelques années ne compilent
même plus sur un GCC récent ?
Combien de fois une décision technique dans le noyau a cassé
cdrecord ?
Alors bien sur, quand les logiciels sont dans la distribution, on
corrige les incompatibilités et la version stable suivante est
cohérente (c'est précisément un des gros avantages du libre), mais il
faut se faire à l'idée que sous la plupart des distributions, si tu
achètes un logiciel externe pour la version N, tu n'as aucune garantie
qu'il continue à marcher après une upgrade du système.