This will be my last post on the subject because I'm tired of wasting my time and to also lose the other, a French version is available at the bottom of this message because my English is too rots
I would like to address two notions someone does not understand that is the financial aspect and the marketing aspect of a project management, Usually managed by the Product Manager On the financial side must understand that time and necessarily the money that is used by developers, integrators and users to update their environment each mounted major versions are not invested in the development of new functionality and search reliability - How an integrator for example it can monetize time spent know a version of dolibarr if after 6 months he must start from zero? - This is why the major functionality we all expect (the advanced accounting, multi-currency, ...) are still not present in the stable release in the core: the community spends time updating its versions In short, the major technical version output timing is counterproductive and flange willingness to invest in dolibarr without dolibarr investment gold will not continue to grow ... On the marketing side, change the numbering rules without giving any explanation to the community (which can not be reduced just to the mailing list of developers ...) is a bad method, misleading limit, because it is believed that there is novelty in dolibarr whereas there is no functionally. At one point we must understand that the project manager to work is not a technique, it is also financial and marketing gold Dolibarr on this aspect is really lagging. Not taking into account two parameters in the roadmap, version numbering is counterproductive. I therefore propose that the next devcamp December to be debated Valencia two points: - The Roadmap major technical versions of Dolibarr that must be passed to a version a year only and ideally by the end of June / early July to enable the integrator / advanced users willing to go up anomalies during the summer and offer the a new version of the more stable and reliable for September, the most active period for implementing an ERP. - A numbering where the first number is the major functional versions of Dolibarr, the second major issue technical version and the latest patch releases Hoping that some end up taking consience it's not just developers who use dolibarr ... ------ Ce sera mon dernier message sur le sujet car j'en ai assez de perdre mon temps et de faire perdre aussi celui des autres, une version en français est disponible en bas de ce message car mon anglais est trop pourrit J'aimerai aborder deux notions quelqu'un ne semble pas comprendre à savoir l'aspect financier et l'aspect marketing d'une gestion de projet, généralement géré par un chef de produit. Sur l'aspect financier il faut comprendre que le temps et forcément l'argent qui est utilisé par les développeurs, intégrateurs et utilisateurs pour mettre à jour leur environnement à chaque monté de versions majeurs n'est pas investie dans le développement de nouvelle fonctionnalité et la recherche de fiabilité - comment un intégrateur par exemple peut-il rentabiliser le temps passé à connaitre une version de dolibarr si au bout de 6 mois il doit tout reprendre de zéro? - c'est la raison pour laquelle les fonctionnalité majeures que nous attendons tous (la comptabilité avancé, le multidevise, ...) ne sont toujours pas présente en version stable dans le core : la communauté passe du temps à mettre à jour ses versions Bref, ce timing de sortie de version technique majeur est contreproductif et bride la volonté d'investir dans dolibarr, or sans investissement dolibarr ne pourra continuer de se développer... Sur l'aspect marketing, changer les règles ne numérotation sans donner la moindre explication à la communauté (qui ne se résume pas juste à la mailing list des développeurs...) est une mauvaise méthode, limite mensongère, car elle fait croire qu'il y a de la nouveauté dans dolibarr alors qu'il n'y en a pas fonctionnellement. A un moment il faut comprendre que le travail de chef de projet n'est pas que technique, il est aussi financier et marketing, or sur cette aspect Dolibarr est vraiment à la traine. Ne pas prendre en compte ses deux paramètres dans le roadmap, la numérotation des versions est contreproductive. C'est pourquoi je propose que lors du prochain devcamp de décembre à Valence soit débattue deux points : - Le Roadmap des versions techniques majeurs de Dolibarr qui doit être passée à une version par an seulement et idéalement pour la fin juin/début juillet afin de permettre au intégrateur/utilisateurs avancées de bonne volonté de remonter les anomalies durant la période estivale et offrir au novice une version des plus stable et fiable pour la rentrée, période la plus active pour mettre en place un ERP. - Une numérotation où le premier numéro correspond aux versions majeures fonctionnelles de dolibarr, le deuxième numéro aux version majeures techniques et le dernier aux versions de correctifs En espérant que certains finissent par prendre consience qu'il n'y a pas que des développeurs qui utilisent dolibarr ... Bien cordialement, Charlie Benke De : Dolibarr-dev [mailto:dolibarr-dev-bounces+charles.fr=benke...@nongnu.org] De la part de Charles Benke Envoyé : mardi 8 novembre 2016 13:32 À : 'Posts about Dolibarr ERP & CRM development and coding' <dolibarr-dev@nongnu.org> Objet : Re: [Dolibarr-dev] Dolibarr 5.0 freeze and new version 4.0.2 As reading on module Accountancy : experimental Multicurrency : develop So call IT as you want IS NOT A MAJOR VERSION You speak that “Version 5.0 has a very good compatibility behaviour with external modules, “ witch external modules have you tested? All present in the dolistore? I would have preferred that we work more on the stability of previous major versions to continue this headlong counterproductive. I hope them we can discuss how the project is managed, it is time after 10 years actually change ... Bien cordialement, Charlie Benke De : Dolibarr-dev [mailto:dolibarr-dev-bounces+charles.fr=benke...@nongnu.org] De la part de Laurent Destailleur (aka Eldy) Envoyé : mardi 8 novembre 2016 00:11 À : ML Dolibarr dev <dolibarr-dev@nongnu.org <mailto:dolibarr-dev@nongnu.org> > Objet : [Dolibarr-dev] Dolibarr 5.0 freeze and new version 4.0.2 Hi Dolibarr developers. Time to start the beta of the next major version has come. The release candidate version should be ready for January, so as usual, we must start the beta period few month ago, so now. To follow modern pratice about namin convention, next major version followin the 4.0 will be called 5.0 and not 4.1. I still don't know why we spent so many times (10 years) to increase the second level of number used commonly to describe a minor chane when it was major release, but well, late is better than never. So, starting from this week-end, the beta period for 5.0 will be launched. No new features will be added from PR. As usual, "started development" are allowed to be continued to be finished for final release. Work on not stable modules are also still opened because such modules won't be visible by users. Among works already started and that are qualified to continue to push PR that are not bu fixed, we may find: - work on advanced accountancy (double party) module, - multicurrency module - work to simplify code to support oauth - website module - management of a VAT code to be able to distinguish different VAT with same rate - theme enhancement to be more responsive designed - uniformization of the look and feel and usae of the dol_banner for all tabs. - translation changes - changes required to allow package generations After the freeze, new features will be suspended until the branch for 5.0 is created. Then merging PR for new features will be possible again into develop branch. Also, architecture, reenginering, or best practice code enhancements will be discarded during this period. Instead any help is welcome to fix all opened bug: See https://github.com/Dolibarr/dolibarr/issues More information on what a "freeze" mean: https://wiki.dolibarr.org/index.php/Category:RoadMap Version 5.0 has a very good compatibility behaviour with external modules, so you can already check your external modules are still working with this version. A Changelog (not yet detailed with coming new features) is available in the current development branch that will be used to start the freeze to give information on what was changed and may need attention of external developers or upgraders. Also, note that a maintenance version, version 4.0.2 was released few days ago to provide recent fixes available for branch 4.0. More information on what a "maintenance version" mean: https://wiki.dolibarr.org/index.php/Category:RoadMap Laurent Destailleur, aka Eldy ------------------------------------------------------------------------------------ Google+: <https://plus.google.com/+LaurentDestailleur-Open-Source-Expert/> https://plus.google.com/+LaurentDestailleur-Open-Source-Expert/ Twitter: <http://www.twitter.com/eldy10> http://www.twitter.com/eldy10 ------------------------------------------------------------------------------------
_______________________________________________ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
