Cette version corrige des bugs mineurs, principalement liés à XML, aux XSLT, et aux fontions de temps, ainsi que quelques crashes.
Le PHP Group recommande ne pas passer en 4.1.1 si on est déjà en 4.1.0 et que les bugs corrigés par cette nouvelle version n'apparaissent pas.
Parallèlement à cela, le travail sur une version 4.2.0 continue.
Aller plus loin
- Release notes (2 clics)
- Téléchargements (2 clics)
- PHP QA Team (2 clics)
- PHP.net (2 clics)
- Zend (3 clics)
# php sur cobalt
Posté par SUrOB . Évalué à 4.
merci
[^] # Re: php sur cobalt
Posté par Joel PALUD . Évalué à 6.
http://pkg.nl.cobalt.com/i386/RaQ4-PHP-4.0.6.pkg(...(...))
Plus généralement, jette un oeil sur :
http://pkg.nl.cobalt.com/packages/(...(...))
Je viens de découvrir que les Cobalt avait des
package spécifiques... je croyais que c'était plus "standard".
# ne pas upgrader?
Posté par a_jr . Évalué à 8.
Je trouve bizarre que l'on suggere de ne pas upgrader a la version 4.1.1 si la 4.1.0 marche et que les bugs n'apparaissent pas.
Concernant tout logiciel, en ici php en particulier, il faut toujours utiliser la version la plus recente sauf si elle a plus de bugs connus que la precedente. Il faut toujours utiliser cette version sur une machine de test afin de valider avec le temps qu'elle peut passer sur une machine dite de production.
Sinon...
Sinon, cela veut dire que:
1/ la version n+1 est pas stable. Alors il ne fallait pas la sortir
2/ la version n contient des bugs, puisque la version n+1 est sortie. Donc on ne peut pas faire confiance a la version n non plus. Sous-entendu: restez ou revenez a la version n-1!!!
3/ si personne n'utilise la version n+1 parce qu'il a ete conseille de garder la version n, il y aura tres peu de rapports de bugs. Donc la version n+2 ne corrigera pas tous les bugs puisqu'on n'en aura trouve que tres peu. Ca fait baisser la qualite.
Resultat, en ce qui concerne php, moi, je reste en 4.0.6 en prod et je risque d'y rester un bon bout de temps. Sur ma machine de developpement, va falloir que je reste aussi en 4.0.6 pour des raisons de compatibilite.
Et comme je suis quand meme un poil aventureux, va falloir que je me trouve un autre port pour faire tourner un apache+php-4.1.1 pour jouer avec.
Bref, les gars, si vous sortez une version que vous ne conseillez pas, pas la peine de la sortir, ca fait baisser la confiance. A moins de faire une branche dite "unstable" comme beaucoup font (linux-2.5.x, debian-unstable, etc).
Le bonjour chez vous,
Yves
[^] # Re: ne pas upgrader?
Posté par Éric (site web personnel) . Évalué à 10.
il y a plein de choses avec lesquelles je ne suis pas d'accord dans ce que tu dis.
Tout d'abord le "il faut toujours utiliser la version la plus recente". Je ne dirais pas de faire le contraire mais ce que tu préconises est absolument à ne pas faire.
Il y a trois types de nouvelles versions :
- celles qui amènent de nouvelles fonctionnalités (nouvelle fonction, nouvelle conf par défaut, compatibilité avec telle ou telle version de lib qui n'était pas supportée avant)
- celles qui amènent des corrections de type fonctionnel (fonction qui avait un comportement bizarre ou qui ne marchait simplement pas)
- celles qui apportent des corrections de sécu
Malheureusement en général c'est un peu des trois.
Tu ne dois mettre à jour QUE si c'est un type "correction de sécu" (et même là il faut regarder si la faille corrigée étaient un problème chez toi). Le reste sert uniquement si tu en as besoin.
Pourquoi ? car si les nouvelles versions amènent des corrections elles amènent aussi des nouvelles erreurs potentielles. Si tu met à jour, la 4.1.1 semble peut etre sans bugs mais personne ne peut prédire que on ne trouvera pas une faille importante de sécu dans cette release dans quelques temps. Ok, on peut toujours en trouver une dans la 4.0.6 mais elle est déjà plus testée, donc potentiellement moins sujette à des problèmes non connus.
Si tu met à jour sans réfléchir à chaque mise à jour tu peux etre sur d'etre vulnérable à presque tous les problèmes qui sont découverts. L'attitude raisonnable est de ne mettre à jour QUE en cas de besoin (un probleme de sécu est un besoin, une optimisation ou nouvelle fonctionnalité ne l'est pas, vu que ca tournait avant). Tu n'envisages les mises à jour non nécessaires que quand le code est suffisement sur (vieux?).
A ton avis pourquoi beaucoup de linux sont en 2.2 (et certains meme en 2.0) ? Pourquoi Free est encore en php3 ? pourquoi tout le monde n'a pas la dernière version d'apache (je suis même convaincu que certaines version sorties comme stables n'ont presque pas été appliquées sur les serveurs de prod) ?
Ce n'est pas uniquement une affaire de temps à passer mais aussi de sécurité (on est plus sur de ce qu'on a que de ce qu'on peut avoir).
Tu dois etre de ceux qui se sont tapé tous les problèmes des 2.4 un à un en mettant à jour à chaque fois .... l'histoire des 2.4 sur linux est un bon exemple sur le pourquoi il ne faut pas appliquer des releases uniquement parce qu'elles sont sorties.
Le problème n'est pas qu'ils sortent une version qui a des problemes c'est que il y a beaucoup de nouveau code, eux n'ont pas (encore) vus de problèmes et elle a l'air de tourner, mais potentiellement elle est moins sure qu'une autre version.
--
pourquoi j'en fais toujours des tartines ?
[^] # Re: ne pas upgrader?
Posté par a_jr . Évalué à 8.
Malheureusement en général c'est un peu des trois.
Malheureusement, oui.
C'est pour cela que je preconise:
1/ d'upgrader
2/ sur des machines de test.
Tu ne dois mettre à jour QUE si c'est un type "correction de sécu"
Tout a fait, mais sur une machine de prod. Et encore, il faut lire le ChangeLog avant pour verifier que le bug est effectivement corrige (j'avais oublie de parler du changelog dans mon precedent post)
Sur une machine de test, je preconise l'upgrade parce que toute machine upgradee permet d'avoir au moins un beta-testeur de plus (euh, je me repete ;-)
A ton avis pourquoi beaucoup de linux sont en 2.2 (et certains meme en 2.0) ? Pourquoi Free est encore en php3 ? pourquoi tout le monde n'a pas la dernière version d'apache (je suis même convaincu que certaines version sorties comme stables n'ont presque pas été appliquées sur les serveurs de prod) ?
Ce n'est pas uniquement une affaire de temps à passer mais aussi de sécurité (on est plus sur de ce qu'on a que de ce qu'on peut avoir).
Parce qu'on est en prod!
Comme on est d'accord sur ce point, j'argumente pas. Par contre, j'ajouterai quand meme que certaines upgrades ne sont pas faites par raison de securite mais pour d'autres raisons:
- changement de licence (php 4 pas aussi libre que php 3, en ce qui concerne free.fr je crois)
- flemme d'upgrader: "ca marche donc je m'en occupe pas".
Dans le second cas, malheureusement de nombreux logiciels contiennent des bugs connus. Ils sont corriges dans des versions dites stables et testees depuis longtemps. Cependant, l'upgrade ne se fait pas. Pourquoi? Un bel exemple: pourquoi garde-t-on netscape 2 ou netscape 3 alors que netscape 4 et netsacpe 6 sont sortis? netscape-4.79 est a mon avis bien plus sur qu'un netscape 3, non?
Autre cas: tar. Sur certaines machines, tar est bogue au point que dans les FAQ de certains logiciels, il est mis que 'si vous arrivez pas a decompresser avec tar, utilisez la version gnu tar'. Si ce probleme est connu au point d'arriver dans les FAQ, c'est que les admins n'ont pas fait leur boulot.
Dans ces cas, et ca revient a ce qu'on disait, l'upgrade devrait se faire pour raison de securite.
En ce qui concerne le noyau, je suis passe tres rapidement au 2.4 chez moi sur ma machine de developpement: APM rulez pour eteindre la machine. Mon serveur, lui, est longtemps reste en 2.2.
Et j'ai effectivement applique la plupart des patchs parce qu'a chaque fois, cela corrigeait un probleme que j'avais (principalement l'APM).
Le problème n'est pas qu'ils sortent une version qui a des problemes c'est que il y a beaucoup de nouveau code, eux n'ont pas (encore) vus de problèmes et elle a l'air de tourner, mais potentiellement elle est moins sure qu'une autre version.
Alors il ne faut pas dire "l'utilisez que si ca corrige des problemes que vous avez". Il faut fournir deux versions, l'une avec les corrections des bugs, et l'autre avec les nouvelles fonctionnalites. Le plus bel exemple (apres le noyau linux): apache.
On en est a la version 2.0 depuis un bon bout de temps deja (on est en RC, mais c'est pareil a mon sens maintenant, depuis le temps). Cependant, a chaque nouvelle version du serveur web 1.3.x, il est mis "upgradez: c'est la version la plus sure qu'il ait jamais existe".
Je precise quand meme que je me tape le ChangeLog a chaque fois avant d'upgrader, afin de voir si y'a des bugs qui apparaissent chez moi. Et seulement dans ce cas j'upgrade. Et je suis toujours en 1.3.x, pas en 2.0.
Voila. Quand je dis qu'il faut upgrader, c'est evidemment pas en prod (sauf si pb de secu). Parce que si personne n'upgrade, alors personne d'autre que l'equipe de dev ne teste le soft et l'equipe de dev n'a pas de retour.
Le bonjour chez vous,
Yves
[^] # Re: ne pas upgrader?
Posté par pas_moi . Évalué à 4.
Un logiciel qui a des bugs ne peut pas franchement être considéré comme un logiciel qui marche... Autrement, il faut m'expliquer ce qu'est un logiciel qui marche pour toi: est-ce un logiciel qui n'a pas encore planté, ou est-ce un logiciel qui, de par les méthodes de développement utilisées, a peu de chance de planter dans le futur?
Certaines sociétés nous ont montré qu'elles penchent plutôt vers le premier choix («Windows XP, le système le plus sûr que Microsoft n'ait jamais créé» jusqu'à ce qu'un bug de la taille de tous ceux déjà trouvés dans les systèmes précédents soit découvert) alors que d'autres développeurs essayent d'appliquer des méthodes de développement/relecture afin d'assurer une certaine qualité au niveau du code (OpenBSD par exemple)...
[^] # Re: ne pas upgrader?
Posté par Éric (site web personnel) . Évalué à 1.
Y'a plein de choses à dire sur MS mais tu peux etre sur que eux aussi font une relecture et un audit du code :). oBSD le fait, les autres OS aussi, faut pas croire, MS aussi a envie de faire des softs sans bugs (sisi).
A savoir si ca suffit c'est autre chose.
Maintenant franchement de mon expérience perso il y a largement autant (qui a dit plus ?) de bugs et failles sur les softs *nix que sur les windows, simplement eux sont corrigés assez vite, et sont assez peu génants justement si on n'a pas la toute derniere version sortie mais des versions bien connues et testées.
[^] # Re: ne pas upgrader?
Posté par pas_moi . Évalué à 3.
J'ai beaucoup de mal à m'en convaincre...
MS aussi a envie de faire des softs sans bugs
Alors là, je ne suis pas loin d'être convaincu du contraire: il n'ont aucun intérêt à faire des softs stables, alors que quelques bugs permettent de faire vendre les nouvelles versions. Quand on voit que certains bugs dans IE refont leur apparition quelques mois après leur correction, on peut se poser des questions.
il y a largement autant (qui a dit plus ?) de bugs et failles sur les softs *nix que sur les windows
Il n'y a pas que le nombre de bugs qui compte, il y a aussi la probabilité de tomber dessus: quand on installe Windows, on se retrouve avec IE et Outlook d'installés; or ce sont les principaux vecteurs de bugs. Sur mes Debian, je n'installe que le minimum (qui est lui aussi parfois buggé, mais de façon bien moindre et, comme tu le dis, c'est bien souvent corrigé plus rapidement/proprement), ce qui permet d'éviter bien des bugs...
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.