Symfony1 relancé !

Posté par Baptiste SIMON (site web personnel) le 06 décembre 2013 à 15:27. Modéré par ZeroHeure. Licence CC By‑SA.

Étiquettes :

déc.

2013

Pour des raisons de facilité de développement, et parce que Symfony1 est à l'arrêt depuis maintenant 1 an, les développeurs du logiciel libre de billetterie informatisée e-venement ont décidé de forker le projet.

Il ne s'agit pas d'une reprise des développements de Symfony1. Il s'agit, pour le moment, juste d'un besoin vécu par les développeurs de retrouver des possibilités d'interagir avec le framework sur lequel est basé leur application métier. En effet, Symfony1 rend encore, malgré ses petits défauts et ses lenteurs, tous les services que l'on peut attendre d'un framework. La quantité de code, de fonctionnalités, de détails développés pour e-venement v2 est telle qu'un changement de framework n'est pas non plus à l'ordre du jour.

Voilà donc Symfony1 exhumé et relancé.
Un appel est lancé sur l'article originel pour toutes les bonnes volontés de reprise spécifique de la maintenance de Symfony1, dont les développeurs se passeraient bien.

Aller plus loin

Article originel sur le site communautaire d'e-venement (294 clics)
e-venement (168 clics)
Repository Subersion symfony-1.5-li (112 clics)
Première release v1.5-li.0 (2,4 Mo) (64 clics)
Libre Informatique, le lead de e-venement (51 clics)

# besoin

Posté par CrEv (site web personnel) le 06 décembre 2013 à 16:41. Évalué à 4.

quel est le besoin ?
cool vous forkez symfony 1 mais pourquoi ? qu'est ce qui ne va pas actuellement, etc ?
- [^] # Re: besoin
  
  Posté par Atem18 (site web personnel) le 06 décembre 2013 à 16:51. Évalué à 2.
  
  Ils n'ont pas envie de passer à Symphony 2. D'après ce que j'ai entendu, les deux versions diffèrent grandement.
  - [^] # Re: besoin
    
    Posté par CrEv (site web personnel) le 06 décembre 2013 à 16:55. Évalué à 1.
    
    Ça ok, mais ça n'en fait pas un besoin pour forker symfony 1.
    Pour que ce soit intéressant il faut qu'il y ait des problèmes dans symfony 1, des manques, quelque chose quoi.
    - [^] # Re: besoin
      
      Posté par Baptiste SIMON (site web personnel) le 06 décembre 2013 à 17:18. Évalué à 4.
      
      il n'y a pas de rébellion en cours en tout cas … il y a juste que c'est indiqué ici : http://symfony.com/legacy
      
      symfony 1.x
      The symfony 1.x Homepage
      
      The symfony 1.x branch of the framework started in 2005 and the latest stable version and long term support release is symfony 1.4. As of November 2012, symfony 1.x is not maintained anymore and you are encouraged to have a look at Symfony2 for any new projects. 7
      
      Comme nous souhaitons continuer à y travailler, nous forkons.
      si c'est problématique, on revient sur cette décision en deux commandes shell hein… ;c)
- [^] # Re: besoin
  
  Posté par ckiller le 06 décembre 2013 à 16:54. Évalué à 3.
  
  C'est marqué sur le site :
  
  "Pour des raisons de facilité de développement, et parce que Symfony1 est à l’arrêt depuis maintenant 1 an, les développeurs de e-venement ont décidé de forker.
  " Attention ! Cette version est encore peu mature. En effet, l’un des objectifs est reprendre l’ensemble des fonctionnalités dépréciées dans PHP et cela demande un travail de fourmis, et nous avons choisi de faire du temps notre allié pour y arriver.
  Les développeurs d’e-venement n’ont pas la prétention de faire une réelle maintenance de Symfony1. Ils parent juste aux nécessités quotidienne. Toute bonne volonté de maintenir spécifiquement ce fork ou de relancer la maintenance officielle de Symfony sont les bienvenues."
  - [^] # Re: besoin
    
    Posté par CrEv (site web personnel) le 06 décembre 2013 à 16:57. Évalué à 0.
    
    parce que Symfony1 est à l’arrêt depuis maintenant 1 an
    
    Le fait qu'un code n'évolue plus ne justifie pas un fork, il faut qu'il y ait une autre raison.
    
    reprendre l’ensemble des fonctionnalités dépréciées dans PHP
    
    ça ok, c'est plutôt une bonne raison.
- [^] # Re: besoin
  
  Posté par Thomas J. (site web personnel) le 06 décembre 2013 à 16:54. Évalué à 2.
  
  La quantité de code, de fonctionnalités, de détails développés pour e-venement v2 est telle qu'un changement de framework n'est pas non plus à l'ordre du jour.
  
  C'est souvent un reproche qui est fait aux frameworks (rails, symfony, etc.) lors des montées de version : en changeant certains paradigmes, les montées de version peuvent être réellement douloureuses pour les développeurs.
  - [^] # Re: besoin
    
    Posté par ʭ ☯ le 06 décembre 2013 à 16:59. Évalué à 4.
    
    Pour le coup, les Symphony 1 et 2 n'ont en commun que le nom…
    
    ⚓ À g'Auch TOUTE! http://afdgauch.online.fr
    - [^] # Re: besoin
      
      Posté par tominardi le 06 décembre 2013 à 17:11. Évalué à 2.
      
      Effectivement, il ne s'agit pas ici d'une montée de version.
      
      Je trouve quand même la stratégie hasardeuse. Il me semble que Symfony 1 a été arrêté pour de bonnes raisons. Et le recrutement autours de Symfony 1 va se faire toujours plus compliqué. L'histoire ne dis pas s'ils ont un projet de refonte derrière.
      - [^] # Re: besoin
        
        Posté par Baptiste SIMON (site web personnel) le 06 décembre 2013 à 17:22. Évalué à 2.
        
        Embaucher des personnes est certes un critère, mais la partie "symfony" de e-venement n'est pas le plus complexe… le logiciel a vraiment tellement de fonctionnalités, de modules, de trucs super spécifiques (impression via une appli web sans passer par le moteur de l'OS, placement numéroté graphique, etc. etc.) que c'est surtout ça qui rend le recrutement périlleux ;c) pas symfony1 :cb
# C'est bien, mais…

Posté par laurentb (site web personnel) le 06 décembre 2013 à 18:31. Évalué à 4.

Tout d'abord, il est certain qu'il y a un besoin d'un Symfony1 maintenu, au moins par rapport aux nouvelles incompatibilités avec PHP 5.5. Symfony2 n'a rien à voir, la migration est tout simplement impossible sans réécriture, de plus son intérêt est plus que discutable.

Cependant il y a déjà plusieurs efforts comme https://github.com/LExpress/symfony1 ou https://github.com/chok/symfony1 - pourquoi un de plus ? Quelles sont les différences ? Et pourquoi SVN ? :(
- [^] # Re: C'est bien, mais…
  
  Posté par Baptiste SIMON (site web personnel) le 06 décembre 2013 à 19:34. Évalué à 2. Dernière modification le 06 décembre 2013 à 19:35.
  
  Je découvre pour ma part les autres initiatives. Je ne sais rien des différences ou des avantages/inconvénients de celui là par rapport aux autres. Éventuellement dans le cadre de e-venement, c'est intéressant parce que l'équipe qui le développe maîtrise ainsi totalement son framework.
  
  On va fouiller ces autres forks. S'ils sont intéressant, on les rejoindra, bien entendu ! Nous n'avons aucune prétention si ce n'est de combler un manque que l'on pensait abyssal ;c) Le fork de LExpress sera essayé dès la semaine prochaine avec e-venement par exemple :cb
  
  Quant à Symfony, c'est juste une question d'histoire et de passé…
  Et puis quand e-venement a démarré en 2006, git n'avait qu'un an et pas ou peu d'infrastructure déjà en place permettant de bosser sereinement avec… ;c)
- [^] # Re: C'est bien, mais…
  
  Posté par Snarky le 07 décembre 2013 à 21:41. Évalué à 4.
  
  Intéressant ces projets. Dans ma boite, impossible de passer en S2, car trop de trucs ont déjà été fait en S1, un jour surement, mais pas tout de suite, pour le changement :).
  
  J'ai fait un peu de profiling récemment sur symfony 1, pour voir comment gagner des perfs, et je me suis rendu compte que sur le rendu d'une page de notre projet qui met 100ms, il y avait presque 30ms juste pour l'initialisation du routing dans le fichier [cache]/config_routing.yml.php (super bonne idée, le coup du unserialize pour instancier des classes…. ça permet de bien perdre du temps).
  Du coup, je pensais faire des modifs "maisons", mais si un projet s'en est déjà chargé, je vais m'y intéresser de près.
  - [^] # Re: C'est bien, mais…
    
    Posté par Baptiste SIMON (site web personnel) le 08 décembre 2013 à 18:15. Évalué à 3.
    super intéressant cette affaire.
    si nous pouvons mutualiser… voici ce que nous avons déjà apporté (et je regarderai également les modifs de LExpress un de ces quatres) :
    - compatibilité > PHP-5.3 (au moins pour ce que nous utilisons, à savoir principalement les preg_replace avec une option /e)
    - retrait du code de propel, pour avoir ça de moins à maintenir
    - possibilité de faire des filtres ordonnés par catégories dans le doctrine:generate-admin (cf. en fin de post)
    - possibilité de faire du doctrine:data-dump sur des ressources (ex: données en blob)
    - résolution d'un bug un peu orphelin dans Doctrine sur les champs NULL dans des cas particuliers
    si on peut mettre des forces en commun, je suis super preneur. n'hésite pas à me/nous contacter, à proposer de rejoindre les autres forks ou de créer un repository spécifique… tout est faisable !
    
    exemple de filtres organisés dans les modules doctrine:generate-admin :
    apps/*/modules/*/config/generator.yml :
```
  filter:
    display:
      Personal: [title, name, firstname, postalcode, city, region_id, country, email]
      Social informations: [familial_quotient_id, familial_situation_id, type_of_resources_id]
      Relations: [groups_list, not_groups_list, organism_id, organism_category_id, professional_type_id]
```
# Pourquoi forker ?

Posté par PapsOu le 09 décembre 2013 à 08:58. Évalué à 1.

La question que je me pose, étant développeur PHP5 Symfony2, c'est combien de temps va prendre cette maintenance d'un framework qui sera (ou n'est) plus utilisé ?

Est-ce qu'une étude à été réalisée pour savoir combien de temps prendrais le fork d'un framework par rapport au temps de migration du projet de SF1 à SF2 ?

J'ai débarqué sous SF2 en Juillet, je ne connais donc pas du tout les détails concernant les pratiques SF1 et celles de SF2, mais cela étant, je trouve ça dommage de se passer de la puissance de SF2… Par contre, ça me fait prendre conscience qu'il faudrait, dans l'idéal, découpler au maximum les dépendances au framework pour faciliter une éventuelle migration vers SF3… (utilisation d'Interface, de Factory, Bridge, Proxy (autres) à tout va pour faciliter la migration….)

Bref, peut on considérer ça comme un aveu que le projet est trop dépendant d'un version de techno particulière ?
- [^] # Re: Pourquoi forker ?
  
  Posté par Nicolas (site web personnel) le 09 décembre 2013 à 09:28. Évalué à 5.
  
  A mon avis le temps de migration de symfony 1 à symfony 2 est bien plus court que la maintenance d'un fork.
  
  Je connais bien symfony 1 (ayant bossé avec de la version 0.8 à 1.4 ); je suis passé il y a un peu plus d'un an à la version 2.
  
  symfony 2 n'a que peu de rapport avec symfony 1 mais même si le vocabulaire a un peu changé, on retrouve rapidement ses petits. Si le projet est bien découplé, le passage de la version 1 à la 2 n'est pas si complexe que cela. On n'a pas besoin de tout réécrire. Toutes les classes métier restent toujours indépendantes du framework.
  
  symfony 2 n'est pas une montagne infranchissable. Evidemment le niveau requis en programmation est un peu plus élevé que pour symfony 1 mais encore une fois rien d'insurmontable.
  - [^] # Re: Pourquoi forker ?
    
    Posté par Baptiste SIMON (site web personnel) le 09 décembre 2013 à 10:57. Évalué à 3.
    
    tout dépend de la quantité et de la finesse de ce qu'il y a à migrer….
- [^] # Re: Pourquoi forker ?
  
  Posté par barmic le 12 décembre 2013 à 11:21. Évalué à 2.
  
  Comme tout projet qui fait une révolution en changeant de version, il y a (à minima) un fork au passage (parce que les gens ne veulent pas changer, parce qu'il y a des changements discutables, parce qu'en changeant tant de chose il est presque impossible d'adresser tous les cas d'usage de la précédente version, etc). On l'a vu avec Gnome3.
  
  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Suivre le flux des commentaires

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