Aller au contenu | Aller au menu | Aller à la recherche

jeudi, août 30 2012

Sortie de Jelix 1.4

Diantre ! 10 mois que je n'ai pas parlé de mon framework PHP Jelix sur mon blog ! Cela date de... la sortie de Jelix 1.3 :-) Et dire que quelques semaines après la 1.3, j'avais annoncé sur la mailing-list que j’accélérerais la cadence des sorties à 2-3 mois. C'est raté. Il faut croire que le rythme est bloqué à 10 mois.

Donc voilà Jelix 1.4 avec sa tonne de nouveautés : cache HTTP, autoload PSR0, templates virtuelles, amélioration de la prise en charge des codes langues, des modules de plus en plus autonomes etc...

Le retard de cette sortie est due à plusieurs choses :

  • Déjà, les vacances d'été, chantiers chez moi etc : j'ai été souvent offline ces dernières semaines :-)
  • La faute à pas de temps
  • La mise en place de docs.jelix.org
  • La libération du code source des sites de Jelix.org

La faute à pas de temps : en effet, j'ai eu un contrat de plusieurs mois (qui se termine), sur un projet hyper intéressant (à base de XUL/javascript), mais plutôt éloigné de chez moi. Donc beaucoup de temps de trajets et de fatigue. Résultat, avec les autres tâches à coté, le projet n'a pas avancé aussi vite que j'aurai voulu

La réalisation du site http://docs.jelix.org a permis de migrer les manuels, du wiki Dokuwiki vers un nouveau système de wiki basé sur Git, et que j'ai développé avec Jelix bien entendu : Gitiwiki. J'en parlerai plus longuement une autre fois. Basculer la documentation sur Git a permis d'accélérer les améliorations du manuel : je peux maintenant écrire en offline (dans le RER par exemple). Par contre, plus en online...Temporairement... Gitiwiki fonctionne pour le moment en lecture seule. Il faut encore que je développe la possibilité d'éditer en ligne :-) (c'est en cours). Cependant, cela ne devrait empêcher personne de contribuer au manuel : il est sur github.

Enfin, comme je disais, j'ai aussi passé du temps à libérer le code source du site jelix.org et bien sûr le code du nouveau site docs.jelix.org, dans l'espoir d'avoir plus d'aide sur tout ce qui fait tourner le projet ;-).

Et puis comme je ne suis pas toujours discipliné, j'ai préféré ces 2-3 derniers mois, à commencer à développer Jelix 1.5 plutôt que de paufiner Jelix 1.4 !

jeudi, septembre 1 2011

Jelix : de Mercurial à Git

Depuis deux ans déjà, j'ai complètement abandonné subversion et utilisé Mercurial pour gérer le code source de mes projets. J'avais choisi Mercurial au départ parce que je devais l'utiliser pour contribuer à Firefox. J'avais alors apprécié le produit et l'avais adopté pour mes autres projets personnels. Pour les projets professionnels comme chez Zoomorama, et ou pour Jelix, nous (moi et mes collègues ou les contributeurs) avions étudié bien sûr Git avant de choisir Mercurial. À l'époque, Mercurial paraissait plus simple d'utilisation : des commandes plus claires, plus concises, moins verbeuse. Il avait aussi un meilleur support multi-plateforme en particulier sous windows. Ce dernier critère me paraissait essentiel par exemple pour Jelix, car j'avais des contributeurs sous Windows.

Lire la suite...

dimanche, novembre 7 2010

Mercurial/Git : ne pas "brancher" est une erreur

Et c'est une erreur que j'ai faite pour le développement de Jelix 1.2. Cela a conduit à un gros retard (presque 1 an !) sur la sortie de la version stable, avec toutes les conséquences qu'un retard de la sortie d'une version d'un projet peut avoir.

Lire la suite...

lundi, juillet 20 2009

En plein dans le Mercure

En ce moment, je m'amuse pas mal avec Mercurial.

Chez Zoomorama, parce que Subversion devenait limitant pour nous, nous avons décidé de migrer vers Mercurial. On a pas mal recherché et discuté des différents avantages et inconvénients entre git et mercurial, et hg nous semble plus approprié pour nos besoins.

  1. Mercurial nous semble plus propre d'un point de vue des commandes (Il n'y a pas 144 scripts différents avec des dépendances dans tout les sens comme dans Git) et il est presque aussi simple à utiliser que subversion. Cela nous fera gagner du temps pour s'approprier l'outil.
  2. Il y a une très bonne documentation (bien que celle de Git semble s'améliorer), entre autre ce guide
  3. Et surtout il a un bon support sur toutes les plateformes, ce qui est important pour nous puisqu'on fait, entre autres choses, des applis multi plateformes basées sur Mozilla.
  4. On utilise Gecko, en le modifiant, et Gecko étant sous Mercurial, ça ne nous fait pas apprendre un nième outils.

Au niveau fonctionnalités, Git et Mercurial se valent je trouve, surtout dans les fonctionnalités de base. Mercurial a beaucoup progressé et comblé son relatif retard ces derniers temps. Et vu qu'on ne va pas forcément utiliser les fonctionnalités super avancées de ces outils ce n'est pas sur ce point qu'on a pu les départager (quoique, j'apprecie beaucoup l'extension mq de Mercurial)... D'un point de vue performance, on n'a pas des projets de plusieurs dizaines de millions de lignes de code, aussi je ne pense pas que Mercurial va nous pénaliser (bien qu'il parait qu'il est plus lent que Git sur certaines opérations).

Le seul inconvénient qu'on lui trouve : le site officiel est moche par rapport à celui de git :-), mais heureusement, il y a un nouveau site plus propre : http://hg-scm.org/.

Un bon comparatif (sans troll et assez objectif je trouve) qui a fini par nous convaincre : Git vs Mercurial.

Et puis, du coté de mes projets perso, je suis en train aussi de passer aussi à Mercurial. Pour Jelix, je viens de monter http://hg.jelix.org. Je dois encore configurer les droits d'accés pour le push via ssh (c'est moins classe à configurer que pour subversion [1]) et quelques autres broutilles (comme modifier les cron des builders de nightlies). Je vais enfin pouvoir commiter dans le train !

À propos de gestionnaire de sources, le projet PHP vient de changer lui aussi de système. Ils ont enfin délaissé CVS pour utiliser Subversion. Je m'étonne toutefois qu'ils ne se soient pas orienté vers Git, Mercurial ou un autre système décentralisé. Surtout que je n'arrive pas à mettre la main sur leurs arguments en faveur de Subversion par rapport à Git/Mercurial.

Notes

[1] en fait non, une fois compris le truc, c'est bien plus puissant, en utilisant http://hg.opensource.lshift.net/mercurial-server/ et je viens de terminer sa configuration :-)