PHP 4.3.3 publié!

Posté par  . Modéré par Fabien Penso.
Étiquettes :
0
27
août
2003
PHP
Annonce de publication de PHP 4.3.3

Après avoir suivi un long processus qualité, PHP 4.3.3 est disponible! Cette version de maintenance résout un bon nombre de bugs découverts dans des versions antérieures de PHP. Elle corrige aussi plusieurs problèmes de sécurité. Il est "vivement" recommandé à tous les utilisateurs d'utiliser cette version aussitôt que possible. PHP 4.3.3 contient la liste suivante et non exhaustive de corrections,
améliorations et ajouts :

* Amélioration du moteur pour utiliser les entrées/sorties Posix et socket
lorsque c'est possible.
* Corrections de plusieurs problèmes de dépassement de capacité
avec les entiers et buffers.
* Correction des jeux de caractères multi-octets qui incluent le caractère
0x5c en tant que second octet des formulaires multipart/form-data.
* each() est désormais compatible avec les clés binaires.
* Améliorations importante de NSAPI SAPI
* Amélioration de l'interface IMAP
* Amélioration de l'interface Interbase
* Ajout d'un gestionnaire DBA 'infile' pour supporter les fichiers .ini
* Ajout des options longues pour les versions CLI & CGI (i.e. --version).
* Ajout de nouveaux paramètres à preg_match*() pour indiquer l'offset de
départ dans la recherche de la chaîne.
* La bibliothèque Expat distribuée passe en version 1.95.6
* La bibliothèque PCRE distribuée passe en version 4.3
* La bibliothèque GD distribuée passe en version 2.0.15
* Plus de 100 corrections de bugs divers.

Pour une liste complète des modifications par rapport à PHP 4.3.2, reportez-vous au fichier NEWS.

Aller plus loin

  • # Re: PHP 4.3.3 publié!

    Posté par  . Évalué à 3.

    > Pour une liste complète des modifications de PHP 4.3.2, reportez-vous au
    > fichier NEWS.

    s/4.3.2/4.3.3/

    non ?
  • # Re: PHP 4.3.3 publié!

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

    Des paquets debian non officiels de php 4.3.3 sont dispos sur

    http://debian.moolfreet.com/(...)
    • [^] # Re: PHP 4.3.3 publié!

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

      J'hésite à les installer sur mon serveur woody en prod, qui utilise encore les packages par défaut.
      Y a t'il des contres indication?
      En plus avoir un site qui a une prononciation si proche d'une spécialité culinaire du nord en cette période de braderie ( Moules Frites) ca me fait bien rire mais ca ne me rassure pas ...
      • [^] # Re: PHP 4.3.3 publié!

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

        Ces paquets sont compilés pour woody et pour des processeurs >=i686 (attention a ce point).

        Les librairies associées sont aussi présentes dans le repository.

        J ai juste pris les sources de PHP 4.3.3, auxquelles j ai appliqué les scripts de packaging des paquets officiels (modifiés juste pour rendre la compilation possible). Il n y a pas de différences majeures avec les paquets officiels, la transition de l un à l autre se fait sans probleme.

        Pour info, ces paquets sont deja en prod sur certains serveurs ici, chez Nexen.

        Au besoin, je fournit les scripts de packaging. Et en cas de souci, je suis dispo...

        moolfreet, c est un delire qui date d el epoque ou j etais encore un petit etudiant. Je suis ouvert a toute autre proposition :)
  • # Et pour PHP5 ??

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

    Je n'ai pas très bien compris l'histoire avec PHP5 et MySQL !?!
    A cause d'un problème de licences on ne pourra plus distributer les deux ensembles ? Il faudra recompiler des libs pour avoir le support Mysql ? Il n'y à plus le connecteurs, une autre base a été préférée ?!! Jusqu'a présent je n'ai entendu que des infos contraditoires, ya quelqu'un dans la salle avec quelques bonnes infos ?

    http://jeremy.zawodny.com/blog/archives/000812.html(...)
    • [^] # Re: Et pour PHP5 ??

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

      non, pour des raisons de licence, ils ne pourront pas distribuer PHP avec l'intégration par défaut du module mysql. En effet, pour integrer le module, il faut le lier à la bibliotheque mysql. Or si on distribue commercialement un produit lier à la bibliotheque Mysql, il faut dorénavant acheter une licence mysql.

      Donc, plus de module mysql installé par défaut. Il faut donc installer les bibliotheque mysql et recompiler PHP pour beneficier du module.
    • [^] # Re: Et pour PHP5 ??

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

      En gros c'est un probléme de liscence MySQL étant sous liscence GPL il ne peut pas être liée avec le code de PHP.

      Sauf si la liscence de PHP est considéré comme une liscence libre pour l'OSI.

      Mais si tu veux vendre une appli commercial en PHP closed source dans l'état actuel des choses tu devra acheter une liscence de MySQL.
      • [^] # Re: Et pour PHP5 ??

        Posté par  . Évalué à 1.

        OK !
        Dans ces conditions, pensez-vous qu'un transfert de l'effort qui a été fournit pour bien intégrer l'utilisation de MySQL avec PHP vers PostgreSQL (licence BSD) soit plus qu'une hypothèse ?

        ... réflexion ...
        Il y a donc très certainement un crénau "marchand" à prendre. Je vois bien quelque société spécialisées proposer des modules/wrappers pour faciliter la bascule de MySQL à PostgreSQL aux entreprises dont l'activité commerciale se retrouve complexifiée.
        ... arrêt de la réflexion, ça a trop chauffé ...
      • [^] # Re: Et pour PHP5 ??

        Posté par  . Évalué à 2.

        C'est penible quand même,

        en tant que devellopeur je me dit que ca fait chier ces histoires de licences...

        en me mettant à la place d'un client/decideur, je me dirai que c'est bancal le libre : un coups c'est mysql un autre PostgreSQL... ca manque de visibilité.


        Je sais pas si j'ai bien compris, la societe mysql ab demande une licence pour un "link", mais d'un autre coté elle propose mysql en GPL.. ya pas moyen de faire un fork (bidon) de mysql(gpl) pour qu'il puisse être linké à php ? ca va pas ca ? ne me dites pas que la licence php ne le permet pas ?! enfin j'en sais rien, si qqun pouvais m'eclairer
        Parceque moi perso compiler php, j'ai essayé merci bien, j'ai fini par prendre le rpm :)
        • [^] # Re: Et pour PHP5 ??

          Posté par  . Évalué à 3.

          non car si il est linké à un logiciel celui-ci doit etre en GPL aussi je crois

          et si ils veulent distribuer une version propriétaire closed source ou je c plus trop quoi, ils peuvent plus

          il sont donc obligés de demander une licence spéciale au détenteur du copyright qui doit etre la société mysql j'imagine

          aller moinssez moi si j'ai dit n'importe quoi
        • [^] # Re: Et pour PHP5 ??

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

          ... je vois pas ce que tu veut faire : on a d'un coté MySQL, sous GPL, et de l'autre PHP, sous une license Libre mais incompatible avec la GPL :
          http://www.gnu.org/licenses/license-list.html#GPLIncompatibleLicens(...)

          D'ailleurs, un fork ne peut pas changer la license d'un projet, sauf si les types qui font le fork ont une autorisation de chacun des contributeurs (la license BSD intègre cette autorisation pour ce que j'en ai compris). Sinon, il suffirait de forker n'importe quel projet pour s'approprier son code source. Dans ces conditions, la GPL servirait à rien.
      • [^] # Re: Et pour Java, il y a le même problèmes

        Posté par  . Évalué à 1.

        Ils font la même chose avec les drivers JDBC(Connect J/3.0) pour MySql.

        Jusqu'a la serie des 2.x les drivers etait sous la license LGPL donc pas de problème pour la distribuer avec une application commercial. La série des 3.x est passé discretement (enfin je trouve) sous license GPL.

        Ce n'est pas extrement grave car il reste bien en dessous des prix de leurs concurents reste à voir si ce nouveau modèle leur sera bénéfique.
      • [^] # Re: Et pour PHP5 ??

        Posté par  . Évalué à 1.

        En gros c'est un probléme de liscence MySQL étant sous liscence GPL il ne peut pas être liée avec le code de PHP.

        Sauf si la liscence de PHP est considéré comme une liscence libre pour l'OSI.


        Sauf que les dirigeants de MySQL ont clairement précisé que des exceptions seraient faites au cas par cas pour certains projets. Je ne crois pas que MySQL AB soit assez bête pour s'aliéner PHP, qui a fait et fait encore une grande partie de son succès. Donc soit ils vont attendre que la licence PHP soit validée par l'OSI, soit ils vont s'arranger avec Zend pour clore l'affaire par une décisions qui satisfera tout le monde...

        (l'info est pas très fraîche, ça date d'il y a des mois et il y avait déjà une enfilade à ce sujet sur Linuxfr)
  • # Re: PHP 4.3.3 publié!

    Posté par  . Évalué à 1.

    Je vais surement me faire huer (ché plus comment ça s'ecrit) mais il y en a (moi) qui (pas frapper) utilise une redhat 8 std (installé avec l'option serveur) + postgresql.
    J'ai donc un apache 2 + postgresql et php 4.2.

    Je voudrai bien passer à php 4.3.x mais la ........ big problem.

    les seuls RPMS dispo sont la plus part du temps pour apache 1.3 ou alors pour une version de apache que je n'ai pas (en tout cas pas celle de la RH).

    Si je met a jours apache (tjs avec des RPMs non officiel, la c'est avec postgres que ca ne marche plus).

    Bref, misere.

    La je suis en train d'essayer de me faire un RPM mais bon, c pas gagné.

    Bref, c un peu la mort pour passer a PHP quand on à une distrib qui n'est pas dans les petits papier de php.net

Suivre le flux des commentaires

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