Je reprend ici le texte (en le modifiant) que j’ai mis dans le topic Prevelement où il n’avait pas ça place.
Les sorties de version de Dolibarr: la Roadmap est fixé depuis maintenant plus de deux an : wiki.dolibarr.org/index.php/Category:RoadMap.
Il serait peux être intéressants de la remettre en question, mais par exemple, la grosse amélioration de la 3.5, c’est le support complet de DoliDroid (application Android pour Dolibarr). Ce qui ne vous concerne peux être pas directement, mais c’est une chouette évolution depuis le temps que l’on parle de cette application.
Si je refait l’histoire la 3.4 est sortie très en retard car nous avions décider de la geler plus tard à cause du DevCamps 2012. Donc la 3.5, n’est ni en avance ni précipitée, elle rattrape juste les deux mois de retard de la 3.4. J’ai demander a reporter la 3.5 car nous voulons faire un autre DevCamps 2013, mais pas avant février 2014, donc non, la 3.5 sortira conformément au planning.
Y a t’il conflit d’intérêt sur la sortie de cette version, pour vendre une application payante (et libre) sur un produit libre et gratuit … Il y a surtout, je pense, une volonté de respecter le planning, le conflit d’intérêt aurait été de ne pas sortir la 3.4 au moins de février et bloquer les autres évolutions jusqu’à ce que soit compatible complètement avec DoliDroid.
Au sujet des modules à racheter à chaque version, c’est les éditeurs de module qui choisissent de vous refaire payer, c’est leur choix, peux être qu’en faisant pression, vous pouvez obtenir plus de flexibilité de leur part sur ce sujet.
Il est fréquent que des dépôt (répository) existe pour chaque module, demander l’accés en lecture a ces dépôt à l’éditeur.
Sur la question des améliorations entre les versions et les souhaits des intégrateurs. C’est simple, si vous, intégrateurs, vous avez des demandes d’évolution qui sont financée, et que vous vous adressez à des développeurs, faite mettre noir sur blanc dans le contrat de service, que vous souhaitez que ces développements soit intégré dans la branche dev de dolibarr (donc pour la future version), et vous ne payer que quand c’est effectivement le cas.
Sur l’intégration des modules dans le core, avec git c’est pas très compliqué, et on travaille tous correctement avec cette outils
Par exemple, conformément a ce qu’on avait dit avec defrance, j’ai essayé d’intégrer Projet v2 gratuit, mais il y avait un travail a faire coté qualité du code du module projet avant de l’intégré. J’ai fait un peu, mais par manque de temps je n’ai pas pu aller au bout des deux démarches. Je garde espoir de trouver le temps de le faire, a moins qu’un autre dev s’en charge. Si cette demarche avait été faite depuis le debut du module, cela fait longtemps qu’il serait dans le core.
J’ai le même problème avec certain de mes module que j’ai laisser traîner sans les intégré par manque de temps ou de volonté (assortiement, import/export multiprix, etc…)
Avec Jfefe, on a essayé de mettre sur les rail un site de financement collaboratif pour de Dolibarr. Ce site n’aura pour but que de mettre en relation les financeur et les intégrateur/développeur, un peu a la sauce codeur.com mais dédier Dolibarr et ceux qui ont le label Partner (oui il faut l’étendre au intégrateur). Ça fait 6 mois qu’il est presque fait, mais on a pas le temps, en ce moment, de le mettre en ligne.
La question de qui a les droits de valider les pull request, aujourd’hui c’est Eldy et Juanjo (2bytes), et Régis, mais il n’intervient plus beaucoup. Quand je vois le nombre de repasse que fait Eldy sur les pull request qu’il a accepter d’intégrée (sur les miennes également ;-), pour ceux qui suive les commit regardez bien ceux qui se nomme « tons of bugs »), je me demande si mettre 4 personnes de plus avec ces droits serait vraiment judicieux.
Aussi utilisons DoliForge. Une pull request qui référence un bug ou une tache de Doliforge est beaucoup plus facilement intégré dans le core que si c’est en vrac. Oui, c’est procédurier et consommateur un peu en temps, mais cela sert vraiment.