J’ouvre cette file pour lancer la discussion sur la sortie des prochaines version de dolibarr et en particulier de la lointaine 4.0.0
Je propose de faire de cette version une LT (Long Terms) et de ne plus faire qu’une version Annuelle ST (Short Term) et une version corrective de la LT (ne touchant pas aux structure des tables)
Pour cette version 4.0 il serait pertinent de revoir l’organisation des éléments natifs de dolibarr afin de les restructurer pour les normaliser selon les règles des modules additionnels. il serait aussi pertinent de revoir l’interfaces IHM (menu, onglets, rendering pattern)
A chacun de poster ici ses réflexions sur le sujet
Intéressant,
j’ajouterai que ce serait bien de résoudre une fois pour toute les questions de traductions des propriértés dans les classes et des colonnes dans les tables. On met tout en anglais partout une bonne fois pour toute au lieu de changer un champ par ci, une propriété par là au fil des versions
Bonjour à tous,
Je vote pour la LTS. En tant qu’intégrateur je suis fatigué des nouvelles versions qui remettent en cause des modules ou des architectures Même si l’enchainement des nouvelles versions peut en rassurer certains sur l’évolution, il serait plus judicieux d’avoir une LTS stabilisée « à mort ». Quand on voit le nombre de bugs non résolus alors qu’une nouvelle release sort, ce n’est pas rassurant.
Il est vrai qu’un travail d’uniformisation serait le bienvenu. Peut importe la langue même si l’anglais et ma préférée (internationalisation de Dolibarr) mais il faut revoir la charte de nommage et des fonctions… Une fois cela s’appelle invoice, une autre ça s’appelle facture ! Pas très cool pour ce genre de choses pour les développeurs. Ce ne sera possible qu’avec une LTS qui sera la base d’une nouvelle version au point au bout de 3 ans mini.
A vous lire…
Je suis également d’accord pour une LTS mais plutôt basée sur une 3.5.x éprouvée que sur une 4.0 toute neuve… surtout si on renomme les colonnes des tables et les variables des classes dans cette dernière (compatibilité des modules, des triggers, etc).
Un petit UP pendant les vacances
Après réflexions et discutions avec les uns et les autres de cette idée de cette histoire de 4.0
je fais une petit synthèse
D’abord je rajoute dans la liste des choses à modifier la génération des éditions pdf : faire quelque chose de plus simple et d’homogène
Ensuite, il faut virer le Français du code et du nommage des modules et des bases de données
Autre piste, tout redévelopper depuis zéro en utilisant un framework genre synphony, cela ne me semble pas le but de cette réflexion
Autre remarque, limiter les modules présents dans dolibarr au strict minimum. Actuellement il y a une 60taines de modules natifs dans la version de base de dolibarr. il faudrait se lmiter à la moitié par défaut et proposer sur un espace comme le dolistore (mais gratuit) les modules optionnels maintenus
Maintenant parlons de planning
nous avons actuellement une nouvelle version ‹ majeure › de dolibarr tous les 6 mois, la 3.6 devrait bientot sortir
Donc 3.7 et 3.8 en 2015, et 3.9 et 4.0 pour la fin 2016
Soit 2 ans et demi pour sortir une 4.0 stable
On va se donner jusqu’à la fin de l’année pour valider les fonctionnalités qui seront présente ou non dans cette version et restructurer la base de données pour renommer les tables avec des termes anglais (idéalement écrire les premiers outils de migrations depuis la version 3.x)
Ensuite l’année 2015 serait consacré à développer le noyau principal et en particulier un modèle de modules standard en reprenant les bonnes pratiques, créer les tests unitaires la documentation…
Enfin l’année 2016 pour développer les modules principaux et les optionnels, cela permettra aux développeurs de modules (comme moi) de migrer leur module.
Certe ce serait confortable, mais perso, je ne le voudrais pour rien au monde ! pour plusieurs raisons :
- il faut dans ce cas donner des droits d’écriture au serveur web sur les répertoires Dolibarr (htdocs et scripts), ce qui créé un énorme trou de sécurité pour les Dolibarr hébergés en mode SAAS.
- Il ne s’agit pas de mettre à jour un site internet, mais de mettre à jour un outil de gestion auquel on a confié la gestion de l’activité d’une société (ou assoc). Donc il ne s’agit pas de faire une mise à jour, mais il faut l’envisager comme une migration avec tout ce que ça suppose comme précautions, études préalables, tests … Bien sûr dolibarr est souvent utilisé dans de petites structures, mais n’empêche, il s’agit de factures, clients, comptabilité…
- je suis de plus en plus allergique à la « versionite aigüe » qu’on voit sur de nombreux projets où dès qu’une version sort, il faut l’avoir. Je travaille beaucoup avec des utilisateurs de Prestashop et suis confronté à ce problème (et depuis peu au bouton qui permet de mettre à jour la version automatiquement…) et les problèmes que les utilisateurs se créent !
- Dans le développement d’un ERP/CRM, notre défi est de proposer une outil le plus stable possible, qui peut être utilisé pendant des années, et qu’on migre si on a besoin de le faire et qu’on a bien préparé la migration.
je ne parlais pas de migration mais juste un système qui permettrais de corriger les bugs de la version courante et qui ne touche pas a la structure données utilisateurs après même si il y a un système automatique il peut y avoir un système manuel histoire d avoir des correctif plus régulièrement que de devoir attendre la version suivante pour corriger certaine erreurs des fois genante
Plutôt de la maintenance donc. Mais ça reste compliqué à faire pour garantir un système stable au maximum, car mis à part les versions publiées, Dolibarr ne propose que les sources gérés via Github, donc pas évident à automatiser une mise à jour corrective.
Bonjour,
Je ne suis pas pour la maj automatique (hors upgrade) Comme déjà dit, Dolibarr est un ERP est donc un outil stratégique pour l’entreprise petite ou grande. L’interaction sur des modules optionnels est trop grande.
Maintenant pourquoi ne pas démarrer cette LTS sur la 3.5.4 qui a l’air stable ? Pourquoi ne pas donner le top départ sur la 3.6 ? Croyez vous vraiment que d’ici 2015/2016 nous aurons renommer les dossiers, les tables, les fonctions… et tout ça en anglais ? Ceux qui mettent le nez dans le code savent que c’est un ÉNORME chantier ! Mais c’est pour un meilleur avenir…
Ce que je regrette c’est que la Team Dolibarr ne s’exprime pas sur le sujet ! Bon c’est les vacances, on va patienter un peu
@+
Oui il y a du boulot, et la communauté Dolibarr recrute des participants actifs, pour animer le forum en partagent des idées mais aussi des développeurs qui se forment pour apporter leur contribution…
Oui c’est les vacances, DeFrance qui a lancé le sujet et moi même (au moins) faisons déjà partie de la communauté et participons, donc la « team » est déjà présente dans la discussion…
Mais même si un débat est intéressant, il est parfois difficile de le traduire en acte, faute de temps, faute de main d’oeuvre, et parce que l’analyse n’est pas toujours suffisante.
Pour les développeurs (et la team), Il s’agit de sortir un outil qui évolue, et qui soit le plus stable possible pour pouvoir être mis en production. Ca demande une gestion de projets et une analyse rigoureuse avant de prendre une voie ou une autre.
Avis aux amateurs : rejoignez la communauté et participez !
Le problème est la définition même de la "Team Dolibarr". Elle existe de fait, mais n'est pas structuré. La team Dolibarr c'est tout les développeurs qui poussent des pull request sur le github pour que le chef de projet technique (Eldy) les intègres, si c'est cohérent. En gros il y a un chef de projet technique qui évite le grand n'importe quoi, qui prend le temps d'intégrer les correctif dans les futures versions, mais pas de direction fonctionnel précise. Si demain je crée une tache sur la forge (ou un autre support peu importe) qui dit, pouvoir gérer des avoirs fournisseurs dans Dolibarr, qui le fait ? Vous, moi, un autre ?
Je pencherais également pour une refonte de beaucoup de partie de Dolibarr (code et ergonomie), par exemple mettre des DataTable partout, tout mettre en anglais (dans le code), bien séparer les logiques fonctionnels et technique dans le code, etc... Mais quel énergie dépensée et financée comment ? Ce type de refonte ne peux pas se faire sur la base du bénévolat, en tous cas cela me parait délicat, mais peut être que je me trompe.
Pour le moment l'association ne finance pas de code, peux être est-il temps que l'on s'y mette... Et au profit de qui ? Quel partenaire ? Ne pas faire de jaloux, ne pas faire de favoritisme au risque de se voir appelé "mafia dolibarr".
J'ai vue une demo de odoo (ex openERP) lors des RMLL et c'est vraiment chouette d'un point de vue ergonomie, faire des listes customiser et des modèles de document PDF avec un plugin LibreOffice c'est génial et super pratique (heureusement pour les listes et tableaux personnalisé Charles a sortie myList et myDoliBoard mais c'est pas aussi intuitif que dans Odoo). La grosse différence c'est que Odoo c'est une entreprise qui fait payer un contrat de support. Coté Dolibarr, il y a quelques entreprises partenaires qui ont cette logique, mais pas d'entité maître de la direction fonctionnel.
On reste sur le fonctionnement qui dit, je développe ce qui est financé, ce que font chaque partenaires et qui le reverse à la communauté lorsque c'est validé par Eldy. Je ne souhaite pas qu'une entreprise prennent le lead fonctionnel de Dolibarr, mais je souhaiterais que des sponsors puissent financer des évolutions majeures.
Autre point la LTS... pourquoi pas, mais comment son nom l'indique, on ne met PAS de nouvelle fonctionnalité entre deux itérations d'une LTS, donc on reste avec les manques fonctionnels et on n'avance pas.... Je prend l'exemple des heures déclaré sur un projet, limité à 24h par une liste déroulante.... Si on veut dire "non non c'est pas une liste, mais on peux mettre ce que l'on veux" ba c'est une nouvelle fonctionnalité et non une correction de bug... C'est une aberration fonctionnel, oui, mais ça fonctionne, donc on reste avec cette liste de 24h dans la LTS pendant 2 ans ? Pendant ce temps là, les version non LTS continue d'évoluer et on va avoir un parc des version de plus en plus disparate, quand on vois que sur ce forum des personnes posent encore des questions pour dolibarr 3.3 (par ce que c'est ce qui est dans les dépôt débian et proposé par OVH)...
Effectivement Dolibarr vie, peut être un peu trop vite, mais au moins il s'y passe des choses. Après je pense qu'il est préférable d'attendre deux ou trois version d'une version de dolibarr pour la déployé en production, tout en faisant des tests régulièrement pour nous remonté les anomalies)
Je pense que pour la prochaine version faudrait pousser à la simplification de la gestion courante. Notamment au niveau des articles à deux niveaux :
possibilité de faire des actions de masse sur les articles ex : tous les articles avec référence xx possibilité de les supprimer si non facturer ou interdis à la vente, la seule solution sur une base de 1000 articles jamais vendu c’est ou à la main de les effacer 1 par 1 ou de passer en phpmyadmin… perso je trouve ça « sale », l’utilisateur ou le gestionnaire n’a rien à faire dans la base de données… à part y foutre le b…
améliorer l’affichage et l’ergonomie si les articles sont hors achat et hors vente ne pas les afficher via une case de choix…
limiter au maximum d’avoir recours systématiquement à des requêtes en base de données pour des choses simples, qui peuvent de régler via les imports… D’ailleurs les imports / sont aussi à améliorer avec la possibilité de pouvoir enfin choisir un modèle « perso » dans lequel ou pourrait choisir les champs qu’ont veux lier… exemple un tiers à un commercial ou à une catégorie etc etc… Ca parait pas grand chose, mais 3 clients avec des bases de prospects tiers à 4500 ont eu raison de ma patience… Surtout quand un tiers peut avoir 2 commerciaux sur x secteurs… fin bref c’est pas gérable de base…
possibilité de bloquer un tiers sur son encours… si encours dépassé plus de facture ou commande possible… Ca à l’air tout bête, mais j’en connait qui ont des clients qui paient pas et des salariés qui vendent encore… Alors oui on peut le mettre en clos mais même là on peut encore lui faire des devis et des factures…
Voilà pour ma liste du père noël… Un grand merci à tous les dev cependant pour leur formidable travail
Effectivement une LTS serait un atout indéniable, à chaque mise à jour de Doli, j’ai perdu pas mal de petites modifications perso que j’avais mises en place pour mes besoins.
