Re: [Dolibarr-association] Dolibarr 4.0.1

classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: [Dolibarr-association] Dolibarr 4.0.1

charles benke.fr

Hello,

10 years is a good year to change his use, be more adult …

5.0 is a REAL major version IF they include as stable multicurancy and accountancy

In other case they will be another disturbish version who decrease the number of sell in the Dolistore.

6 month between 2 major version freeze the creativity of developpers, We have waiting 3 years to have the accountancy stable in Dolibarr and without the crownfunding of darkjeff, I suppose that we have to wait 3 years more this major feature …

 

Once again I ask to change the scheduling of the major release to 1 by year and I propose to plan a vote for change the roadmap ASAP

 

Bien cordialement,

Charlie Benke

 

De : Dolibarr-association [mailto:dolibarr-association-bounces+charles.fr=[hidden email]] De la part de The mailing-list for Dolibarr foundation members
Envoyé : samedi 15 octobre 2016 11:47
À : ML Dolibarr dev <[hidden email]>; ML Dolibarr Foundation <[hidden email]>
Objet : [Dolibarr-association] Dolibarr 4.0.1

 

Hi.

Just a note to let you know that dolibarr 4.0.1 has been released.
4.0.1 is just a very minor bugfix version compared to 4.0 to fix issues discovered just after release of the major version 4.0

The current development branch should also be frozen soon to start the 5.0 beta period. Goal is to release 5.0 in january as stated in the roadmap we follow from 10 years now (1 major version in january and 1 in july)

Version can be downloaded from official portal https://www.dolibarr.org


_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Dolibarr-association] Dolibarr 4.0.1

olivier geffroy
Hi all 

I spoke for accountancy 

we have some minor bugs to correct but the main step will be purchase credit note, bookkeeping (freeze bookkeping entry) and VAT (european vat)

we begin this in november but I'm not sure it will be finish for december, at least we will try to achieve all bugs corrections and VAT 

Best regards 



2016-10-15 14:51 GMT+02:00 Charles Benke <[hidden email]>:

Hello,

10 years is a good year to change his use, be more adult …

5.0 is a REAL major version IF they include as stable multicurancy and accountancy

In other case they will be another disturbish version who decrease the number of sell in the Dolistore.

6 month between 2 major version freeze the creativity of developpers, We have waiting 3 years to have the accountancy stable in Dolibarr and without the crownfunding of darkjeff, I suppose that we have to wait 3 years more this major feature …

 

Once again I ask to change the scheduling of the major release to 1 by year and I propose to plan a vote for change the roadmap ASAP

 

Bien cordialement,

Charlie Benke

 

De : Dolibarr-association [mailto:[hidden email]=[hidden email]] De la part de The mailing-list for Dolibarr foundation members
Envoyé : samedi 15 octobre 2016 11:47
À : ML Dolibarr dev <[hidden email]>; ML Dolibarr Foundation <[hidden email]>
Objet : [Dolibarr-association] Dolibarr 4.0.1

 

Hi.

Just a note to let you know that dolibarr 4.0.1 has been released.
4.0.1 is just a very minor bugfix version compared to 4.0 to fix issues discovered just after release of the major version 4.0

The current development branch should also be frozen soon to start the 5.0 beta period. Goal is to release 5.0 in january as stated in the roadmap we follow from 10 years now (1 major version in january and 1 in july)

Version can be downloaded from official portal https://www.dolibarr.org


_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev




--
Merci d'avance a tous ceux qui vont partager la vidéo dans ma signature ^^
Olivier Geffroy
Consultant Informatique

-------------------------------------
Jeffinfo SARL
29 rue de la Gare 59320 Ennetieres en Weppes
[hidden email]
Gsm : 0608632740
Skype : darkj3ff


_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Dolibarr-association] Dolibarr 4.0.1

Maxime Kohlhaas-2
In reply to this post by charles benke.fr
Hi all,

Regarding the current release management, I (speaking also for ATM) think that having 2 releases per year is a very good thing.
This shows community members that Dolibarr is very active, users that the project is very much alive and that they don't have to wait for more than a year to have a new functionality.

On the development side, we strongly think that short delays between releases is the best because the beta stage is reduced and so are the bugfix. The more new things you have to test and fix, the longer and harder this will be. There's already a lack of testers and bugfixers, so having more for them will be discouraging.

Finally, I don't see where the developer creativity is reduced with this system.

Of course I (again we at ATM) are open to discussion, especially when you will visit us in Valence on December 9/10/11 ;)

Bien cordialement,

--
Maxime Kohlhaas | Consultant associé
------------------------------------------------------------------------------------
Tél : 06 33 42 92 43

2016-10-17 18:38 GMT+02:00 The mailing-list for Dolibarr foundation members <[hidden email]>:
Hello

I agree with Charlie and not only for creativity reason.
I think this point as to be debated to the next devcamp in Valencia.

Regards

Philippe Scoffoni


Le 15/10/2016 à 14:51, Charles Benke a écrit :

Hello,

10 years is a good year to change his use, be more adult …

5.0 is a REAL major version IF they include as stable multicurancy and accountancy

In other case they will be another disturbish version who decrease the number of sell in the Dolistore.

6 month between 2 major version freeze the creativity of developpers, We have waiting 3 years to have the accountancy stable in Dolibarr and without the crownfunding of darkjeff, I suppose that we have to wait 3 years more this major feature …

 

Once again I ask to change the scheduling of the major release to 1 by year and I propose to plan a vote for change the roadmap ASAP

 

Bien cordialement,

Charlie Benke

 

De : Dolibarr-association [[hidden email]] De la part de The mailing-list for Dolibarr foundation members
Envoyé : samedi 15 octobre 2016 11:47
À : ML Dolibarr dev [hidden email]; ML Dolibarr Foundation [hidden email]
Objet : [Dolibarr-association] Dolibarr 4.0.1

 

Hi.

Just a note to let you know that dolibarr 4.0.1 has been released.
4.0.1 is just a very minor bugfix version compared to 4.0 to fix issues discovered just after release of the major version 4.0

The current development branch should also be frozen soon to start the 5.0 beta period. Goal is to release 5.0 in january as stated in the roadmap we follow from 10 years now (1 major version in january and 1 in july)

Version can be downloaded from official portal https://www.dolibarr.org



_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev




_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Dolibarr-association] Dolibarr 4.0.1

cam.lafit@azerttyu.net
Hi

I don't know if one, two or more releases each year is good. As user is without interest.

The more important is to have an easier update. Actually I know only two projects very nice to update : dolibarr and piwik.

As developper, other aspects, I don't try anymore to use plugin, because is often broken or without maintenance. Also I don't try to propose PR or patch, between two releases I'm sure to lost these changes. Actually it's easier to maintain locals patchs and run a routine after each update.

And dolibarr communication is poor, for example, release notification are often forget in this list.

Km

_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Dolibarr-association] Dolibarr 4.0.1

Maxime Kohlhaas
Hi Km,

Thanks for sharing this.
I agree, Dolibarr migration is pretty nice !

Regarding communication, this is a work in progress. From now on, we'll have systematic annoucement when a major version is released, minor version too, why not. A communication group has been started within the fundation with the goal to better communicate with the community. We already are present on social medias, but this dev mailing-list and the dolistore customers are 2 audiences we poorly communicate with (not to say not at all).

About your concerns around PRs and plugins, I'm sorry you feel that way. PRs are usually correctly integrated and not lost. Plugins are the responsibility of their developers. Personnaly, our plugins are upgraded with the new releases

--
Maxime Kohlhaas | Consultant associé
------------------------------------------------------------------------------------
Tél : 06 33 42 92 43

2016-10-19 10:02 GMT+02:00 [hidden email] <[hidden email]>:
Hi

I don't know if one, two or more releases each year is good. As user is without interest.

The more important is to have an easier update. Actually I know only two projects very nice to update : dolibarr and piwik.

As developper, other aspects, I don't try anymore to use plugin, because is often broken or without maintenance. Also I don't try to propose PR or patch, between two releases I'm sure to lost these changes. Actually it's easier to maintain locals patchs and run a routine after each update.

And dolibarr communication is poor, for example, release notification are often forget in this list.

Km

_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev




_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Dolibarr-association] Dolibarr 4.0.1

cam.lafit@azerttyu.net
Hi

Thanks for sharing this.
I agree, Dolibarr migration is pretty nice !

but only core part, modules looks more problematic to update.
 
Regarding communication, this is a work in progress.

Yes I saw this :) But looks again difficult. But it's better :)
 
From now on, we'll have systematic annoucement when a major version is released, minor version too, why not. A communication group has been started within the fundation with the goal to better communicate with the community. We already are present on social medias, but this dev mailing-list and the dolistore customers are 2 audiences we poorly communicate with (not to say not at all).

I don't understand logic, dolibarr users/community are on forum, mailinglist but piority is social network, strange
 
About your concerns around PRs and plugins, I'm sorry you feel that way. PRs are usually correctly integrated and not lost.

Maybe now, I'll try again. But I'm not sure. My fear is to lost again energy to nothing.
 
Plugins are the responsibility of their developers. Personnaly, our plugins are upgraded with the new releases

I'm not module developper then I don't know if is complicate or not to follow release and provide. As user, i prefer to have my own script and don't use module. In my use case ratio time spend / bug / patch is too heavy.

Thanks a lot

km

_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Dolibarr-association] Dolibarr 4.0.1

Sasa Ostrouska
In reply to this post by Maxime Kohlhaas


On Wed, Oct 19, 2016 at 12:37 PM, Maxime Kohlhaas <[hidden email]> wrote:
Hi Km,

Thanks for sharing this.
I agree, Dolibarr migration is pretty nice !

Regarding communication, this is a work in progress. From now on, we'll have systematic annoucement when a major version is released, minor version too, why not. A communication group has been started within the fundation with the goal to better communicate with the community. We already are present on social medias, but this dev mailing-list and the dolistore customers are 2 audiences we poorly communicate with (not to say not at all).

Which is the main channel you use to announce the releases ? I do not saw it on twitter, facebook or other social media, I do not see it so
often here.

My proposal would be to automate this process, so when a git tag is created then a post-commit hook sends out an email. I think this is really simple. A mail does not need much in it than the link to the released software and maybe a link to the github changelog to see what is new.
 
Rgds
Saxa

About your concerns around PRs and plugins, I'm sorry you feel that way. PRs are usually correctly integrated and not lost. Plugins are the responsibility of their developers. Personnaly, our plugins are upgraded with the new releases

--
Maxime Kohlhaas | Consultant associé
------------------------------------------------------------------------------------
Tél : 06 33 42 92 43

2016-10-19 10:02 GMT+02:00 [hidden email] <[hidden email]>:
Hi

I don't know if one, two or more releases each year is good. As user is without interest.

The more important is to have an easier update. Actually I know only two projects very nice to update : dolibarr and piwik.

As developper, other aspects, I don't try anymore to use plugin, because is often broken or without maintenance. Also I don't try to propose PR or patch, between two releases I'm sure to lost these changes. Actually it's easier to maintain locals patchs and run a routine after each update.

And dolibarr communication is poor, for example, release notification are often forget in this list.

Km

_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev




_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev



_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Dolibarr-association] Dolibarr 4.0.1

Maxime Kohlhaas
Hi Saxa,

Posts are made on facebook and twitter, we will sned it to the mail-list also from now on.
I don't know if this can be automated because after creating the git tag, there are several tasks done by Eldy today to have all packages generated and available on dowload platform.

--
Maxime Kohlhaas | Consultant associé
------------------------------------------------------------------------------------
Tél : 06 33 42 92 43

2016-10-19 14:55 GMT+02:00 Sasa Ostrouska <[hidden email]>:


On Wed, Oct 19, 2016 at 12:37 PM, Maxime Kohlhaas <[hidden email]> wrote:
Hi Km,

Thanks for sharing this.
I agree, Dolibarr migration is pretty nice !

Regarding communication, this is a work in progress. From now on, we'll have systematic annoucement when a major version is released, minor version too, why not. A communication group has been started within the fundation with the goal to better communicate with the community. We already are present on social medias, but this dev mailing-list and the dolistore customers are 2 audiences we poorly communicate with (not to say not at all).

Which is the main channel you use to announce the releases ? I do not saw it on twitter, facebook or other social media, I do not see it so
often here.

My proposal would be to automate this process, so when a git tag is created then a post-commit hook sends out an email. I think this is really simple. A mail does not need much in it than the link to the released software and maybe a link to the github changelog to see what is new.
 
Rgds
Saxa

About your concerns around PRs and plugins, I'm sorry you feel that way. PRs are usually correctly integrated and not lost. Plugins are the responsibility of their developers. Personnaly, our plugins are upgraded with the new releases

--
Maxime Kohlhaas | Consultant associé
------------------------------------------------------------------------------------
Tél : <a href="tel:06%2033%2042%2092%2043" value="+33633429243" target="_blank">06 33 42 92 43

2016-10-19 10:02 GMT+02:00 [hidden email] <[hidden email]>:
Hi

I don't know if one, two or more releases each year is good. As user is without interest.

The more important is to have an easier update. Actually I know only two projects very nice to update : dolibarr and piwik.

As developper, other aspects, I don't try anymore to use plugin, because is often broken or without maintenance. Also I don't try to propose PR or patch, between two releases I'm sure to lost these changes. Actually it's easier to maintain locals patchs and run a routine after each update.

And dolibarr communication is poor, for example, release notification are often forget in this list.

Km

_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev




_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev



_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev




_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Dolibarr-association] Dolibarr 4.0.1

Doursenaud, Raphaël

2016-10-19 15:50 GMT+02:00 Maxime Kohlhaas <[hidden email]>:
I don't know if this can be automated because after creating the git tag, there are several tasks done by Eldy today to have all packages generated and available on dowload platform.

That's your problem, right here.

All this process should be automated. We have Travis CI in place that can do all the work (and tests !!!). There is no good reason to have this job done manually.
But again, this requires time and energy and no one seem to care enough (I certainly don't anymore).

Once upon a time, I drafted such a release process. It's still lying dormant on the wiki : https://wiki.dolibarr.org/index.php/ReleaseProcess
Feel free to build upon it!

Cheers,

Raphaël Doursenaud
Directeur technique (CTO)
+33 (0)5 35 53 97 13 - +33 (0)6 68 48 20 10

Technopole Hélioparc
2 avenue du Président Pierre Angot
64053 PAU CEDEX 9
SARL GPC.solutions au capital de 7 500 € - R.C.S. PAU 528 995 921

_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Dolibarr-association] Dolibarr 4.0.1

Developpement | Open-DSI
In reply to this post by cam.lafit@azerttyu.net
Hi

Thanks to Camille for pointing the main problem : Module and ratio time spend / bug / patch
As integrator of Dolibarr, it's not "sustainable" for me to test every six month Dolibarr and the modules I'm commonly using. Today I only install 3.9. Maybe next year, I will uprade to 5.0 or not... depending of what functions will be added or remaining experimental.
Modules are too often broken by new version. On the Dolistore you can see module labeled 3.x-4.0 who are in fact broken with the last version or doesn't exist for the current version of Dolibarr. I think it's not good for the reputation of Dolibarr.
I'll be pleased to discuss about this subject in Valence :-)

Regards
Philippe Scoffoni - Open-DSI


Le 19/10/2016 à 15:14, [hidden email] a écrit :
Hi

Thanks for sharing this.
I agree, Dolibarr migration is pretty nice !

but only core part, modules looks more problematic to update.
 
Regarding communication, this is a work in progress.

Yes I saw this :) But looks again difficult. But it's better :)
 
From now on, we'll have systematic annoucement when a major version is released, minor version too, why not. A communication group has been started within the fundation with the goal to better communicate with the community. We already are present on social medias, but this dev mailing-list and the dolistore customers are 2 audiences we poorly communicate with (not to say not at all).

I don't understand logic, dolibarr users/community are on forum, mailinglist but piority is social network, strange
 
About your concerns around PRs and plugins, I'm sorry you feel that way. PRs are usually correctly integrated and not lost.

Maybe now, I'll try again. But I'm not sure. My fear is to lost again energy to nothing.
 
Plugins are the responsibility of their developers. Personnaly, our plugins are upgraded with the new releases

I'm not module developper then I don't know if is complicate or not to follow release and provide. As user, i prefer to have my own script and don't use module. In my use case ratio time spend / bug / patch is too heavy.

Thanks a lot

km


_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev


_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Dolibarr-association] Dolibarr 4.0.1

Sasa Ostrouska
In reply to this post by Maxime Kohlhaas


On Wed, Oct 19, 2016 at 1:50 PM, Maxime Kohlhaas <[hidden email]> wrote:
Hi Saxa,

Posts are made on facebook and twitter, we will sned it to the mail-list also from now on.
I don't know if this can be automated because after creating the git tag, there are several tasks done by Eldy today to have all packages generated and available on dowload platform.

Hi Maxime, maybe I looked badly, but I saw only the anounce of 4.0 and not 4.0.1 anyway, its a part where we should be better with it.
As for the work need to be done by the release manager I think, the real problem is that this work is mostly concentrated on Eldy. Automating a lot of tasks can be done, I do not want to speak about how he does his parts as I do not know it. My suggestion is simple,
which would really solve a lot of issues we see here on this mailing list.

Another solution would also be to make the most part of the upload and release automated. Usually this is make a tag in the RCS , create a distributable package, upload it to some server and then lastly announce it. Of course depending of the infrastructure it is not possible to
automate 100% of the work, but it is possible to do a script uploading and sending a mail as well as posting to twitter, I have no idea about posting to the facebook. But for sure its easy to automate the posting to the mailing list.

Another issue we many times saw here is that the tags not always correspond to the released tarball, this is more problematic in my opinion and just reflects the manual work where human error occurs.

Rgds
Saxa
 
--
Maxime Kohlhaas | Consultant associé
------------------------------------------------------------------------------------
Tél : 06 33 42 92 43

2016-10-19 14:55 GMT+02:00 Sasa Ostrouska <[hidden email]>:


On Wed, Oct 19, 2016 at 12:37 PM, Maxime Kohlhaas <[hidden email]> wrote:
Hi Km,

Thanks for sharing this.
I agree, Dolibarr migration is pretty nice !

Regarding communication, this is a work in progress. From now on, we'll have systematic annoucement when a major version is released, minor version too, why not. A communication group has been started within the fundation with the goal to better communicate with the community. We already are present on social medias, but this dev mailing-list and the dolistore customers are 2 audiences we poorly communicate with (not to say not at all).

Which is the main channel you use to announce the releases ? I do not saw it on twitter, facebook or other social media, I do not see it so
often here.

My proposal would be to automate this process, so when a git tag is created then a post-commit hook sends out an email. I think this is really simple. A mail does not need much in it than the link to the released software and maybe a link to the github changelog to see what is new.
 
Rgds
Saxa

About your concerns around PRs and plugins, I'm sorry you feel that way. PRs are usually correctly integrated and not lost. Plugins are the responsibility of their developers. Personnaly, our plugins are upgraded with the new releases

--
Maxime Kohlhaas | Consultant associé
------------------------------------------------------------------------------------
Tél : <a href="tel:06%2033%2042%2092%2043" value="+33633429243" target="_blank">06 33 42 92 43

2016-10-19 10:02 GMT+02:00 [hidden email] <[hidden email]>:
Hi

I don't know if one, two or more releases each year is good. As user is without interest.

The more important is to have an easier update. Actually I know only two projects very nice to update : dolibarr and piwik.

As developper, other aspects, I don't try anymore to use plugin, because is often broken or without maintenance. Also I don't try to propose PR or patch, between two releases I'm sure to lost these changes. Actually it's easier to maintain locals patchs and run a routine after each update.

And dolibarr communication is poor, for example, release notification are often forget in this list.

Km

_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev




_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev



_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev




_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev



_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Dolibarr-association] Dolibarr 4.0.1

charles benke.fr
In reply to this post by Developpement | Open-DSI

Actually I maintain 22 modules, some are simple, some are complex. To test all of them correctly (use all feature, modify doc, …) each time a new major version of Dolibarr is release is more than 2 full weeks long for Romain an me...

During the month a new version comes out, sales of modules on dolistore are halved cut (according to my information it is not related to my modules only).

 

I could do as some others … , just change the version number and wait for my clients put bugs me but I do not find it honest

 

Most integrators with whom I work no longer wish to upgrade versions as there are no major advances between two versions either-called major

The final version of each major costs money and energy to NOTHING: just to show that development teams are able to release two versions per year, two versions full of vacuum .

 

We have all been waiting for new accountancy module for 2 years. The time spent to release a new version will have better been employed to work on this strategic module…

 

 

Bien cordialement,

Charlie Benke

 

De : Dolibarr-dev [mailto:dolibarr-dev-bounces+charles.fr=[hidden email]] De la part de Developpement | Open-DSI
Envoyé : mercredi 19 octobre 2016 16:24
À : Posts about Dolibarr ERP & CRM development and coding <[hidden email]>
Cc : [hidden email]
Objet : Re: [Dolibarr-dev] [Dolibarr-association] Dolibarr 4.0.1

 

Hi

Thanks to Camille for pointing the main problem : Module and ratio time spend / bug / patch
As integrator of Dolibarr, it's not "sustainable" for me to test every six month Dolibarr and the modules I'm commonly using. Today I only install 3.9. Maybe next year, I will uprade to 5.0 or not... depending of what functions will be added or remaining experimental.
Modules are too often broken by new version. On the Dolistore you can see module labeled 3.x-4.0 who are in fact broken with the last version or doesn't exist for the current version of Dolibarr. I think it's not good for the reputation of Dolibarr.
I'll be pleased to discuss about this subject in Valence :-)

Regards
Philippe Scoffoni - Open-DSI


Le 19/10/2016 à 15:14, [hidden email] a écrit :

Hi

 

Thanks for sharing this.

I agree, Dolibarr migration is pretty nice !

 

but only core part, modules looks more problematic to update.

 

Regarding communication, this is a work in progress.

 

Yes I saw this :) But looks again difficult. But it's better :)

 

From now on, we'll have systematic annoucement when a major version is released, minor version too, why not. A communication group has been started within the fundation with the goal to better communicate with the community. We already are present on social medias, but this dev mailing-list and the dolistore customers are 2 audiences we poorly communicate with (not to say not at all).

 

I don't understand logic, dolibarr users/community are on forum, mailinglist but piority is social network, strange

 

About your concerns around PRs and plugins, I'm sorry you feel that way. PRs are usually correctly integrated and not lost.

 

Maybe now, I'll try again. But I'm not sure. My fear is to lost again energy to nothing.

 

Plugins are the responsibility of their developers. Personnaly, our plugins are upgraded with the new releases

 

I'm not module developper then I don't know if is complicate or not to follow release and provide. As user, i prefer to have my own script and don't use module. In my use case ratio time spend / bug / patch is too heavy.

Thanks a lot

 

km




_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev

 


_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Dolibarr-association] Dolibarr 4.0.1

Doursenaud, Raphaël

Same thing, automate.

Unit tests and functional tests FTW.

Granted it takes some time to write but the effort is worth it ans it's a sane habit to have.

Check out the module template I maintain for a starting point : https://github.com/Dolibarr/dolibarr-module-template

Yes, I have a blog post in the works about that but I'm too busy with paying jobs at the moment.


Le 19 oct. 2016 4:50 PM, "Charles Benke" <[hidden email]> a écrit :

Actually I maintain 22 modules, some are simple, some are complex. To test all of them correctly (use all feature, modify doc, …) each time a new major version of Dolibarr is release is more than 2 full weeks long for Romain an me...

During the month a new version comes out, sales of modules on dolistore are halved cut (according to my information it is not related to my modules only).

 

I could do as some others … , just change the version number and wait for my clients put bugs me but I do not find it honest

 

Most integrators with whom I work no longer wish to upgrade versions as there are no major advances between two versions either-called major

The final version of each major costs money and energy to NOTHING: just to show that development teams are able to release two versions per year, two versions full of vacuum .

 

We have all been waiting for new accountancy module for 2 years. The time spent to release a new version will have better been employed to work on this strategic module…

 

 

Bien cordialement,

Charlie Benke

 

De : Dolibarr-dev [mailto:[hidden email]=[hidden email]] De la part de Developpement | Open-DSI
Envoyé : mercredi 19 octobre 2016 16:24
À : Posts about Dolibarr ERP & CRM development and coding <[hidden email]>
Cc : [hidden email]
Objet : Re: [Dolibarr-dev] [Dolibarr-association] Dolibarr 4.0.1

 

Hi

Thanks to Camille for pointing the main problem : Module and ratio time spend / bug / patch
As integrator of Dolibarr, it's not "sustainable" for me to test every six month Dolibarr and the modules I'm commonly using. Today I only install 3.9. Maybe next year, I will uprade to 5.0 or not... depending of what functions will be added or remaining experimental.
Modules are too often broken by new version. On the Dolistore you can see module labeled 3.x-4.0 who are in fact broken with the last version or doesn't exist for the current version of Dolibarr. I think it's not good for the reputation of Dolibarr.
I'll be pleased to discuss about this subject in Valence :-)

Regards
Philippe Scoffoni - Open-DSI


Le 19/10/2016 à 15:14, [hidden email] a écrit :

Hi

 

Thanks for sharing this.

I agree, Dolibarr migration is pretty nice !

 

but only core part, modules looks more problematic to update.

 

Regarding communication, this is a work in progress.

 

Yes I saw this :) But looks again difficult. But it's better :)

 

From now on, we'll have systematic annoucement when a major version is released, minor version too, why not. A communication group has been started within the fundation with the goal to better communicate with the community. We already are present on social medias, but this dev mailing-list and the dolistore customers are 2 audiences we poorly communicate with (not to say not at all).

 

I don't understand logic, dolibarr users/community are on forum, mailinglist but piority is social network, strange

 

About your concerns around PRs and plugins, I'm sorry you feel that way. PRs are usually correctly integrated and not lost.

 

Maybe now, I'll try again. But I'm not sure. My fear is to lost again energy to nothing.

 

Plugins are the responsibility of their developers. Personnaly, our plugins are upgraded with the new releases

 

I'm not module developper then I don't know if is complicate or not to follow release and provide. As user, i prefer to have my own script and don't use module. In my use case ratio time spend / bug / patch is too heavy.

Thanks a lot

 

km




_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev

 


_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev


Technopole Hélioparc
2 avenue du Président Pierre Angot
64053 PAU CEDEX 9
SARL GPC.solutions au capital de 7 500 € - R.C.S. PAU 528 995 921

_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Dolibarr-association] Dolibarr 4.0.1

Laurent Destailleur (aka Eldy)
In reply to this post by charles benke.fr
Your argue is not coherent.
You say you want less version so you have to test your module less often. It also meas your customer upgrade version less often.

So why just don't you make your tests every 2 versions. Result will be same. You will work only every 1 year instead of every 6 month, and your customer would be able to upgrade only every 1 year (once your module is validated for the version) instead of every 6 month.

It's just your choice and the choice of your customer.

Having a release every 1 year, means nor integrator, nor users have choice. Also it means a lower quality and exponentiel work to make upgrade.
But if you prefer to upgrade your module once per year, just do it. You can, it's just a choice you must do. It is not because there is a new version, that you must upgrade your module. If you prefer to follow a 1 year release, just follow this rythm and ask you customer to follow also this rythm. The only difference is that the ryhtm is defined by you instead of being imposed be a dolibarr low release rythm.
And i think it is better to let integrator to decide their release/upgrade frequency then having this decied/forced by Dolibarr.












 

2016-10-19 16:49 GMT+02:00 Charles Benke <[hidden email]>:

Actually I maintain 22 modules, some are simple, some are complex. To test all of them correctly (use all feature, modify doc, …) each time a new major version of Dolibarr is release is more than 2 full weeks long for Romain an me...

During the month a new version comes out, sales of modules on dolistore are halved cut (according to my information it is not related to my modules only).

 

I could do as some others … , just change the version number and wait for my clients put bugs me but I do not find it honest

 

Most integrators with whom I work no longer wish to upgrade versions as there are no major advances between two versions either-called major

The final version of each major costs money and energy to NOTHING: just to show that development teams are able to release two versions per year, two versions full of vacuum .

 

We have all been waiting for new accountancy module for 2 years. The time spent to release a new version will have better been employed to work on this strategic module…

 

 

Bien cordialement,

Charlie Benke

 

De : Dolibarr-dev [mailto:[hidden email]=[hidden email]] De la part de Developpement | Open-DSI
Envoyé : mercredi 19 octobre 2016 16:24
À : Posts about Dolibarr ERP & CRM development and coding <[hidden email]>
Cc : [hidden email]
Objet : Re: [Dolibarr-dev] [Dolibarr-association] Dolibarr 4.0.1

 

Hi

Thanks to Camille for pointing the main problem : Module and ratio time spend / bug / patch
As integrator of Dolibarr, it's not "sustainable" for me to test every six month Dolibarr and the modules I'm commonly using. Today I only install 3.9. Maybe next year, I will uprade to 5.0 or not... depending of what functions will be added or remaining experimental.
Modules are too often broken by new version. On the Dolistore you can see module labeled 3.x-4.0 who are in fact broken with the last version or doesn't exist for the current version of Dolibarr. I think it's not good for the reputation of Dolibarr.
I'll be pleased to discuss about this subject in Valence :-)

Regards
Philippe Scoffoni - Open-DSI




Le 19/10/2016 à 15:14, [hidden email] a écrit :

Hi

 

Thanks for sharing this.

I agree, Dolibarr migration is pretty nice !

 

but only core part, modules looks more problematic to update.

 

Regarding communication, this is a work in progress.

 

Yes I saw this :) But looks again difficult. But it's better :)

 

From now on, we'll have systematic annoucement when a major version is released, minor version too, why not. A communication group has been started within the fundation with the goal to better communicate with the community. We already are present on social medias, but this dev mailing-list and the dolistore customers are 2 audiences we poorly communicate with (not to say not at all).

 

I don't understand logic, dolibarr users/community are on forum, mailinglist but piority is social network, strange

 

About your concerns around PRs and plugins, I'm sorry you feel that way. PRs are usually correctly integrated and not lost.

 

Maybe now, I'll try again. But I'm not sure. My fear is to lost again energy to nothing.

 

Plugins are the responsibility of their developers. Personnaly, our plugins are upgraded with the new releases

 

I'm not module developper then I don't know if is complicate or not to follow release and provide. As user, i prefer to have my own script and don't use module. In my use case ratio time spend / bug / patch is too heavy.

Thanks a lot

 

km




_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev

 


_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev




--
------------------------------------------------------------------------------------
Google+: https://plus.google.com/+LaurentDestailleur-Open-Source-Expert/
Facebook: https://www.facebook.com/Destailleur.Laurent
------------------------------------------------------------------------------------
* Dolibarr (Project leader): http://www.dolibarr.org (make a donation for Dolibarr project via Paypal: [hidden email])
* AWStats (Author) : http://awstats.sourceforge.net (make a donation for AWStats project via Paypal: [hidden email])
* AWBot (Author) : http://awbot.sourceforge.net
* CVSChangeLogBuilder (Author) : http://cvschangelogb.sourceforge.net



_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Dolibarr-association] Dolibarr 4.0.1

Developpement | Open-DSI
It's not only a question of integrator... I agree with you Laurent and I
have made the choices you propose...

Many dolibarr's users (most ?) doesn't ask for technical help. They go
to the Dolibarr web site, download the last version, install it and go
to the Dolistore. They buy extension, install it and.... "sometimes" it
doesn't work...
I have had so many problen switching to 3.9 with different module from
different sources...
For this kind of people version number is not a significant information...

> Having a release every 1 year, means nor integrator, nor users have
> choice.
A 6 month cycle release for an ERP as no interest for users . They live
on very more long time... No company will ask to have an upgrade every 6
month so why giving them a version every 6 months...
> Also it means a lower quality and exponentiel work to make upgrade.
Can you detail this point ? Devops approach ? So why not release every 3
months to achieve better quality ?

  I think we can have two level : one for the developpers and integrator
and one for the users for example like LibreOffice with "fresh" and
"stable" version. The stable version is a long term support version and
is by default proposed to the users...

Sorry if my languages seems to be "rude", but my english is very poor as
you can see and it's difficult for me to "mettre les formes"
I do not want to create a flameware :-)
Just discuss....

Regards

Philippe Scoffoni

_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Dolibarr-association] Dolibarr 4.0.1

charles benke.fr
In reply to this post by Laurent Destailleur (aka Eldy)

OK

 

If I follow your argumentation … I will deliver a brand new version of all my modules each week, because I have decide to planned like this

Even if the version is not enough tested, even the previous release have some know bug, even if the document are not upgraded …

And I will explain to my disgruntled customers that this is a good method to make a better quality and simplify their upgrade ...

 

Release a version every 6 months because FOR YOU is more simple is not acceptable. I do not develop modules dolibarr because it is easy but because it allows users to better manage their company, create growth, the emploies ...

 

If the major release issued every 6 months was free of bug, stable and did not require another install/update after barely one month to correct the most glaring bugs that will not be dramatic

 

The minimum straightforwardness that we can have with users downloading a new major release is to explain that this version DO NOT BE USED IN PRODUCTION.

 

 

Bien cordialement,

Charlie Benke

 

De : Dolibarr-dev [mailto:dolibarr-dev-bounces+charles.fr=[hidden email]] De la part de Laurent Destailleur (aka Eldy)
Envoyé : mercredi 19 octobre 2016 17:34
À : Posts about Dolibarr ERP & CRM development and coding <[hidden email]>
Objet : Re: [Dolibarr-dev] [Dolibarr-association] Dolibarr 4.0.1

 

Your argue is not coherent.

You say you want less version so you have to test your module less often. It also meas your customer upgrade version less often.

 

So why just don't you make your tests every 2 versions. Result will be same. You will work only every 1 year instead of every 6 month, and your customer would be able to upgrade only every 1 year (once your module is validated for the version) instead of every 6 month.

 

It's just your choice and the choice of your customer.

 

Having a release every 1 year, means nor integrator, nor users have choice. Also it means a lower quality and exponentiel work to make upgrade.

But if you prefer to upgrade your module once per year, just do it. You can, it's just a choice you must do. It is not because there is a new version, that you must upgrade your module. If you prefer to follow a 1 year release, just follow this rythm and ask you customer to follow also this rythm. The only difference is that the ryhtm is defined by you instead of being imposed be a dolibarr low release rythm.

And i think it is better to let integrator to decide their release/upgrade frequency then having this decied/forced by Dolibarr.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

2016-10-19 16:49 GMT+02:00 Charles Benke <[hidden email]>:

Actually I maintain 22 modules, some are simple, some are complex. To test all of them correctly (use all feature, modify doc, …) each time a new major version of Dolibarr is release is more than 2 full weeks long for Romain an me...

During the month a new version comes out, sales of modules on dolistore are halved cut (according to my information it is not related to my modules only).

 

I could do as some others … , just change the version number and wait for my clients put bugs me but I do not find it honest

 

Most integrators with whom I work no longer wish to upgrade versions as there are no major advances between two versions either-called major

The final version of each major costs money and energy to NOTHING: just to show that development teams are able to release two versions per year, two versions full of vacuum .

 

We have all been waiting for new accountancy module for 2 years. The time spent to release a new version will have better been employed to work on this strategic module…

 

 

Bien cordialement,

Charlie Benke

 

De : Dolibarr-dev [mailto:[hidden email]=[hidden email]] De la part de Developpement | Open-DSI
Envoyé : mercredi 19 octobre 2016 16:24
À : Posts about Dolibarr ERP & CRM development and coding <[hidden email]>
Cc : [hidden email]
Objet : Re: [Dolibarr-dev] [Dolibarr-association] Dolibarr 4.0.1

 

Hi

Thanks to Camille for pointing the main problem : Module and ratio time spend / bug / patch
As integrator of Dolibarr, it's not "sustainable" for me to test every six month Dolibarr and the modules I'm commonly using. Today I only install 3.9. Maybe next year, I will uprade to 5.0 or not... depending of what functions will be added or remaining experimental.
Modules are too often broken by new version. On the Dolistore you can see module labeled 3.x-4.0 who are in fact broken with the last version or doesn't exist for the current version of Dolibarr. I think it's not good for the reputation of Dolibarr.
I'll be pleased to discuss about this subject in Valence :-)

Regards
Philippe Scoffoni - Open-DSI




Le 19/10/2016 à 15:14, [hidden email] a écrit :

Hi

 

Thanks for sharing this.

I agree, Dolibarr migration is pretty nice !

 

but only core part, modules looks more problematic to update.

 

Regarding communication, this is a work in progress.

 

Yes I saw this :) But looks again difficult. But it's better :)

 

From now on, we'll have systematic annoucement when a major version is released, minor version too, why not. A communication group has been started within the fundation with the goal to better communicate with the community. We already are present on social medias, but this dev mailing-list and the dolistore customers are 2 audiences we poorly communicate with (not to say not at all).

 

I don't understand logic, dolibarr users/community are on forum, mailinglist but piority is social network, strange

 

About your concerns around PRs and plugins, I'm sorry you feel that way. PRs are usually correctly integrated and not lost.

 

Maybe now, I'll try again. But I'm not sure. My fear is to lost again energy to nothing.

 

Plugins are the responsibility of their developers. Personnaly, our plugins are upgraded with the new releases

 

I'm not module developper then I don't know if is complicate or not to follow release and provide. As user, i prefer to have my own script and don't use module. In my use case ratio time spend / bug / patch is too heavy.

Thanks a lot

 

km



_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev

 


_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev



 

--

------------------------------------------------------------------------------------

Google+: https://plus.google.com/+LaurentDestailleur-Open-Source-Expert/
Facebook: 
https://www.facebook.com/Destailleur.Laurent

------------------------------------------------------------------------------------

* Dolibarr (Project leader): http://www.dolibarr.org (make a donation for Dolibarr project via Paypal: [hidden email])

* AWStats (Author) : http://awstats.sourceforge.net (make a donation for AWStats project via Paypal: [hidden email])

* AWBot (Author) : http://awbot.sourceforge.net

* CVSChangeLogBuilder (Author) : http://cvschangelogb.sourceforge.net

 

 


_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Dolibarr-association] Dolibarr 4.0.1

Laurent Destailleur (aka Eldy)
I don't understand. You say "If the major release issued every 6 months was free of bug, stable and did not require another install/update after barely one month to correct the most glaring bugs that will not be dramatic"

Every experimented developper know that this argument is the best argument to ask to have more release than 2 per year. And you ask less. So why using an argue to ask more release: The more is the delay between 2 versions, the more is the bug rate on production (that's why more and more project are increasing the release frequency) and difficulty to have a stable version is an exponential of the number of feature added or modified. So your argue is just incomprehensible.

I used on production each version, as soon as it is release and announced and I have no problem. Also the stability of a version depends on bugs fixes during the beta period and number of unit tests added when added new future. Developers must work on this direction instead of an "against productive" idea.








2016-10-19 21:34 GMT+02:00 Charles Benke <[hidden email]>:

OK

 

If I follow your argumentation … I will deliver a brand new version of all my modules each week, because I have decide to planned like this

Even if the version is not enough tested, even the previous release have some know bug, even if the document are not upgraded …

And I will explain to my disgruntled customers that this is a good method to make a better quality and simplify their upgrade ...

 

Release a version every 6 months because FOR YOU is more simple is not acceptable. I do not develop modules dolibarr because it is easy but because it allows users to better manage their company, create growth, the emploies ...

 

If the major release issued every 6 months was free of bug, stable and did not require another install/update after barely one month to correct the most glaring bugs that will not be dramatic

 

The minimum straightforwardness that we can have with users downloading a new major release is to explain that this version DO NOT BE USED IN PRODUCTION.

 

 

Bien cordialement,

Charlie Benke

 

De : Dolibarr-dev [mailto:[hidden email]=[hidden email]] De la part de Laurent Destailleur (aka Eldy)
Envoyé : mercredi 19 octobre 2016 17:34
À : Posts about Dolibarr ERP & CRM development and coding <[hidden email]>

Objet : Re: [Dolibarr-dev] [Dolibarr-association] Dolibarr 4.0.1

 

Your argue is not coherent.

You say you want less version so you have to test your module less often. It also meas your customer upgrade version less often.

 

So why just don't you make your tests every 2 versions. Result will be same. You will work only every 1 year instead of every 6 month, and your customer would be able to upgrade only every 1 year (once your module is validated for the version) instead of every 6 month.

 

It's just your choice and the choice of your customer.

 

Having a release every 1 year, means nor integrator, nor users have choice. Also it means a lower quality and exponentiel work to make upgrade.

But if you prefer to upgrade your module once per year, just do it. You can, it's just a choice you must do. It is not because there is a new version, that you must upgrade your module. If you prefer to follow a 1 year release, just follow this rythm and ask you customer to follow also this rythm. The only difference is that the ryhtm is defined by you instead of being imposed be a dolibarr low release rythm.

And i think it is better to let integrator to decide their release/upgrade frequency then having this decied/forced by Dolibarr.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

2016-10-19 16:49 GMT+02:00 Charles Benke <[hidden email]>:

Actually I maintain 22 modules, some are simple, some are complex. To test all of them correctly (use all feature, modify doc, …) each time a new major version of Dolibarr is release is more than 2 full weeks long for Romain an me...

During the month a new version comes out, sales of modules on dolistore are halved cut (according to my information it is not related to my modules only).

 

I could do as some others … , just change the version number and wait for my clients put bugs me but I do not find it honest

 

Most integrators with whom I work no longer wish to upgrade versions as there are no major advances between two versions either-called major

The final version of each major costs money and energy to NOTHING: just to show that development teams are able to release two versions per year, two versions full of vacuum .

 

We have all been waiting for new accountancy module for 2 years. The time spent to release a new version will have better been employed to work on this strategic module…

 

 

Bien cordialement,

Charlie Benke

 

De : Dolibarr-dev [mailto:[hidden email]=[hidden email]] De la part de Developpement | Open-DSI
Envoyé : mercredi 19 octobre 2016 16:24
À : Posts about Dolibarr ERP & CRM development and coding <[hidden email]>
Cc : [hidden email]
Objet : Re: [Dolibarr-dev] [Dolibarr-association] Dolibarr 4.0.1

 

Hi

Thanks to Camille for pointing the main problem : Module and ratio time spend / bug / patch
As integrator of Dolibarr, it's not "sustainable" for me to test every six month Dolibarr and the modules I'm commonly using. Today I only install 3.9. Maybe next year, I will uprade to 5.0 or not... depending of what functions will be added or remaining experimental.
Modules are too often broken by new version. On the Dolistore you can see module labeled 3.x-4.0 who are in fact broken with the last version or doesn't exist for the current version of Dolibarr. I think it's not good for the reputation of Dolibarr.
I'll be pleased to discuss about this subject in Valence :-)

Regards
Philippe Scoffoni - Open-DSI




Le 19/10/2016 à 15:14, [hidden email] a écrit :

Hi

 

Thanks for sharing this.

I agree, Dolibarr migration is pretty nice !

 

but only core part, modules looks more problematic to update.

 

Regarding communication, this is a work in progress.

 

Yes I saw this :) But looks again difficult. But it's better :)

 

From now on, we'll have systematic annoucement when a major version is released, minor version too, why not. A communication group has been started within the fundation with the goal to better communicate with the community. We already are present on social medias, but this dev mailing-list and the dolistore customers are 2 audiences we poorly communicate with (not to say not at all).

 

I don't understand logic, dolibarr users/community are on forum, mailinglist but piority is social network, strange

 

About your concerns around PRs and plugins, I'm sorry you feel that way. PRs are usually correctly integrated and not lost.

 

Maybe now, I'll try again. But I'm not sure. My fear is to lost again energy to nothing.

 

Plugins are the responsibility of their developers. Personnaly, our plugins are upgraded with the new releases

 

I'm not module developper then I don't know if is complicate or not to follow release and provide. As user, i prefer to have my own script and don't use module. In my use case ratio time spend / bug / patch is too heavy.

Thanks a lot

 

km



_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev

 


_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev



 

--

------------------------------------------------------------------------------------

Google+: https://plus.google.com/+LaurentDestailleur-Open-Source-Expert/
Facebook: 
https://www.facebook.com/Destailleur.Laurent

------------------------------------------------------------------------------------

* Dolibarr (Project leader): http://www.dolibarr.org (make a donation for Dolibarr project via Paypal: [hidden email])

* AWStats (Author) : http://awstats.sourceforge.net (make a donation for AWStats project via Paypal: [hidden email])

* AWBot (Author) : http://awbot.sourceforge.net

* CVSChangeLogBuilder (Author) : http://cvschangelogb.sourceforge.net

 

 


_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev




--
------------------------------------------------------------------------------------
Google+: https://plus.google.com/+LaurentDestailleur-Open-Source-Expert/
Facebook: https://www.facebook.com/Destailleur.Laurent
------------------------------------------------------------------------------------
* Dolibarr (Project leader): http://www.dolibarr.org (make a donation for Dolibarr project via Paypal: [hidden email])
* AWStats (Author) : http://awstats.sourceforge.net (make a donation for AWStats project via Paypal: [hidden email])
* AWBot (Author) : http://awbot.sourceforge.net
* CVSChangeLogBuilder (Author) : http://cvschangelogb.sourceforge.net



_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Dolibarr-association] Dolibarr 4.0.1

olivier geffroy
It's depends of the final user 

let's says for a company (who use dolibarr) and make less than 100K per month and don't have a lot of externals modules, 2 update per year is easy

for a big company 1 update per year is enough and with dolibarr isn't a problem to stay in 3.8 and to migrate in 4.0 and squeeze the 3.9 (for example)

my 2 cents

2016-10-20 10:58 GMT+02:00 Laurent Destailleur (aka Eldy) <[hidden email]>:
I don't understand. You say "If the major release issued every 6 months was free of bug, stable and did not require another install/update after barely one month to correct the most glaring bugs that will not be dramatic"

Every experimented developper know that this argument is the best argument to ask to have more release than 2 per year. And you ask less. So why using an argue to ask more release: The more is the delay between 2 versions, the more is the bug rate on production (that's why more and more project are increasing the release frequency) and difficulty to have a stable version is an exponential of the number of feature added or modified. So your argue is just incomprehensible.

I used on production each version, as soon as it is release and announced and I have no problem. Also the stability of a version depends on bugs fixes during the beta period and number of unit tests added when added new future. Developers must work on this direction instead of an "against productive" idea.








2016-10-19 21:34 GMT+02:00 Charles Benke <[hidden email]>:

OK

 

If I follow your argumentation … I will deliver a brand new version of all my modules each week, because I have decide to planned like this

Even if the version is not enough tested, even the previous release have some know bug, even if the document are not upgraded …

And I will explain to my disgruntled customers that this is a good method to make a better quality and simplify their upgrade ...

 

Release a version every 6 months because FOR YOU is more simple is not acceptable. I do not develop modules dolibarr because it is easy but because it allows users to better manage their company, create growth, the emploies ...

 

If the major release issued every 6 months was free of bug, stable and did not require another install/update after barely one month to correct the most glaring bugs that will not be dramatic

 

The minimum straightforwardness that we can have with users downloading a new major release is to explain that this version DO NOT BE USED IN PRODUCTION.

 

 

Bien cordialement,

Charlie Benke

 

De : Dolibarr-dev [mailto:[hidden email]=[hidden email]] De la part de Laurent Destailleur (aka Eldy)
Envoyé : mercredi 19 octobre 2016 17:34
À : Posts about Dolibarr ERP & CRM development and coding <[hidden email]>

Objet : Re: [Dolibarr-dev] [Dolibarr-association] Dolibarr 4.0.1

 

Your argue is not coherent.

You say you want less version so you have to test your module less often. It also meas your customer upgrade version less often.

 

So why just don't you make your tests every 2 versions. Result will be same. You will work only every 1 year instead of every 6 month, and your customer would be able to upgrade only every 1 year (once your module is validated for the version) instead of every 6 month.

 

It's just your choice and the choice of your customer.

 

Having a release every 1 year, means nor integrator, nor users have choice. Also it means a lower quality and exponentiel work to make upgrade.

But if you prefer to upgrade your module once per year, just do it. You can, it's just a choice you must do. It is not because there is a new version, that you must upgrade your module. If you prefer to follow a 1 year release, just follow this rythm and ask you customer to follow also this rythm. The only difference is that the ryhtm is defined by you instead of being imposed be a dolibarr low release rythm.

And i think it is better to let integrator to decide their release/upgrade frequency then having this decied/forced by Dolibarr.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

2016-10-19 16:49 GMT+02:00 Charles Benke <[hidden email]>:

Actually I maintain 22 modules, some are simple, some are complex. To test all of them correctly (use all feature, modify doc, …) each time a new major version of Dolibarr is release is more than 2 full weeks long for Romain an me...

During the month a new version comes out, sales of modules on dolistore are halved cut (according to my information it is not related to my modules only).

 

I could do as some others … , just change the version number and wait for my clients put bugs me but I do not find it honest

 

Most integrators with whom I work no longer wish to upgrade versions as there are no major advances between two versions either-called major

The final version of each major costs money and energy to NOTHING: just to show that development teams are able to release two versions per year, two versions full of vacuum .

 

We have all been waiting for new accountancy module for 2 years. The time spent to release a new version will have better been employed to work on this strategic module…

 

 

Bien cordialement,

Charlie Benke

 

De : Dolibarr-dev [mailto:[hidden email]=[hidden email]] De la part de Developpement | Open-DSI
Envoyé : mercredi 19 octobre 2016 16:24
À : Posts about Dolibarr ERP & CRM development and coding <[hidden email]>
Cc : [hidden email]
Objet : Re: [Dolibarr-dev] [Dolibarr-association] Dolibarr 4.0.1

 

Hi

Thanks to Camille for pointing the main problem : Module and ratio time spend / bug / patch
As integrator of Dolibarr, it's not "sustainable" for me to test every six month Dolibarr and the modules I'm commonly using. Today I only install 3.9. Maybe next year, I will uprade to 5.0 or not... depending of what functions will be added or remaining experimental.
Modules are too often broken by new version. On the Dolistore you can see module labeled 3.x-4.0 who are in fact broken with the last version or doesn't exist for the current version of Dolibarr. I think it's not good for the reputation of Dolibarr.
I'll be pleased to discuss about this subject in Valence :-)

Regards
Philippe Scoffoni - Open-DSI




Le 19/10/2016 à 15:14, [hidden email] a écrit :

Hi

 

Thanks for sharing this.

I agree, Dolibarr migration is pretty nice !

 

but only core part, modules looks more problematic to update.

 

Regarding communication, this is a work in progress.

 

Yes I saw this :) But looks again difficult. But it's better :)

 

From now on, we'll have systematic annoucement when a major version is released, minor version too, why not. A communication group has been started within the fundation with the goal to better communicate with the community. We already are present on social medias, but this dev mailing-list and the dolistore customers are 2 audiences we poorly communicate with (not to say not at all).

 

I don't understand logic, dolibarr users/community are on forum, mailinglist but piority is social network, strange

 

About your concerns around PRs and plugins, I'm sorry you feel that way. PRs are usually correctly integrated and not lost.

 

Maybe now, I'll try again. But I'm not sure. My fear is to lost again energy to nothing.

 

Plugins are the responsibility of their developers. Personnaly, our plugins are upgraded with the new releases

 

I'm not module developper then I don't know if is complicate or not to follow release and provide. As user, i prefer to have my own script and don't use module. In my use case ratio time spend / bug / patch is too heavy.

Thanks a lot

 

km



_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev

 


_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev



 

--

------------------------------------------------------------------------------------

Google+: https://plus.google.com/+LaurentDestailleur-Open-Source-Expert/
Facebook: 
https://www.facebook.com/Destailleur.Laurent

------------------------------------------------------------------------------------

* Dolibarr (Project leader): http://www.dolibarr.org (make a donation for Dolibarr project via Paypal: [hidden email])

* AWStats (Author) : http://awstats.sourceforge.net (make a donation for AWStats project via Paypal: [hidden email])

* AWBot (Author) : http://awbot.sourceforge.net

* CVSChangeLogBuilder (Author) : http://cvschangelogb.sourceforge.net

 

 


_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev




--
------------------------------------------------------------------------------------
Google+: https://plus.google.com/+LaurentDestailleur-Open-Source-Expert/
Facebook: https://www.facebook.com/Destailleur.Laurent
------------------------------------------------------------------------------------
* Dolibarr (Project leader): http://www.dolibarr.org (make a donation for Dolibarr project via Paypal: [hidden email])
* AWStats (Author) : http://awstats.sourceforge.net (make a donation for AWStats project via Paypal: [hidden email])
* AWBot (Author) : http://awbot.sourceforge.net
* CVSChangeLogBuilder (Author) : http://cvschangelogb.sourceforge.net



_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev




--
Merci d'avance a tous ceux qui vont partager la vidéo dans ma signature ^^
Olivier Geffroy
Consultant Informatique

-------------------------------------
Jeffinfo SARL
29 rue de la Gare 59320 Ennetieres en Weppes
[hidden email]
Gsm : 0608632740
Skype : darkj3ff


_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Dolibarr-association] Dolibarr 4.0.1

charles benke.fr

Hello Again

Dolibarr 4.0.2 just delivered that we speak about freeze (one more time the 5.0 …)

So keep calm and just count

2 month for beta version (November, December) 2 other for the release candidate (Janurary, feburary) and we finaly delivery a 5.0 in march … WE don’t respect the roadmap

SO what will be in this new version ?

-          The suppression of jquery datatables plugin, used by myList and some other additional modules…, just because they made some problems with dolidroid …

 

It's fine to have a roadmap in planning terms (which are not required since the schedule speaks of January and July so it was March and September)

But it would be more important to have a schedule on functionality is added or is removed ...

 

 

 

Bien cordialement,

Charlie Benke

 

De : Dolibarr-dev [mailto:dolibarr-dev-bounces+charles.fr=[hidden email]] De la part de Olivier Geffroy
Envoyé : jeudi 20 octobre 2016 11:08
À : Posts about Dolibarr ERP & CRM development and coding <[hidden email]>
Objet : Re: [Dolibarr-dev] [Dolibarr-association] Dolibarr 4.0.1

 

It's depends of the final user 

 

let's says for a company (who use dolibarr) and make less than 100K per month and don't have a lot of externals modules, 2 update per year is easy

 

for a big company 1 update per year is enough and with dolibarr isn't a problem to stay in 3.8 and to migrate in 4.0 and squeeze the 3.9 (for example)

 

my 2 cents

 

2016-10-20 10:58 GMT+02:00 Laurent Destailleur (aka Eldy) <[hidden email]>:

I don't understand. You say "If the major release issued every 6 months was free of bug, stable and did not require another install/update after barely one month to correct the most glaring bugs that will not be dramatic"

 

Every experimented developper know that this argument is the best argument to ask to have more release than 2 per year. And you ask less. So why using an argue to ask more release: The more is the delay between 2 versions, the more is the bug rate on production (that's why more and more project are increasing the release frequency) and difficulty to have a stable version is an exponential of the number of feature added or modified. So your argue is just incomprehensible.

 

I used on production each version, as soon as it is release and announced and I have no problem. Also the stability of a version depends on bugs fixes during the beta period and number of unit tests added when added new future. Developers must work on this direction instead of an "against productive" idea.

 

 

 

 

 

 

 

2016-10-19 21:34 GMT+02:00 Charles Benke <[hidden email]>:

OK

 

If I follow your argumentation … I will deliver a brand new version of all my modules each week, because I have decide to planned like this

Even if the version is not enough tested, even the previous release have some know bug, even if the document are not upgraded …

And I will explain to my disgruntled customers that this is a good method to make a better quality and simplify their upgrade ...

 

Release a version every 6 months because FOR YOU is more simple is not acceptable. I do not develop modules dolibarr because it is easy but because it allows users to better manage their company, create growth, the emploies ...

 

If the major release issued every 6 months was free of bug, stable and did not require another install/update after barely one month to correct the most glaring bugs that will not be dramatic

 

The minimum straightforwardness that we can have with users downloading a new major release is to explain that this version DO NOT BE USED IN PRODUCTION.

 

 

Bien cordialement,

Charlie Benke

 

De : Dolibarr-dev [mailto:[hidden email]=[hidden email]] De la part de Laurent Destailleur (aka Eldy)
Envoyé : mercredi 19 octobre 2016 17:34
À : Posts about Dolibarr ERP & CRM development and coding <[hidden email]>

Objet : Re: [Dolibarr-dev] [Dolibarr-association] Dolibarr 4.0.1

 

Your argue is not coherent.

You say you want less version so you have to test your module less often. It also meas your customer upgrade version less often.

 

So why just don't you make your tests every 2 versions. Result will be same. You will work only every 1 year instead of every 6 month, and your customer would be able to upgrade only every 1 year (once your module is validated for the version) instead of every 6 month.

 

It's just your choice and the choice of your customer.

 

Having a release every 1 year, means nor integrator, nor users have choice. Also it means a lower quality and exponentiel work to make upgrade.

But if you prefer to upgrade your module once per year, just do it. You can, it's just a choice you must do. It is not because there is a new version, that you must upgrade your module. If you prefer to follow a 1 year release, just follow this rythm and ask you customer to follow also this rythm. The only difference is that the ryhtm is defined by you instead of being imposed be a dolibarr low release rythm.

And i think it is better to let integrator to decide their release/upgrade frequency then having this decied/forced by Dolibarr.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

2016-10-19 16:49 GMT+02:00 Charles Benke <[hidden email]>:

Actually I maintain 22 modules, some are simple, some are complex. To test all of them correctly (use all feature, modify doc, …) each time a new major version of Dolibarr is release is more than 2 full weeks long for Romain an me...

During the month a new version comes out, sales of modules on dolistore are halved cut (according to my information it is not related to my modules only).

 

I could do as some others … , just change the version number and wait for my clients put bugs me but I do not find it honest

 

Most integrators with whom I work no longer wish to upgrade versions as there are no major advances between two versions either-called major

The final version of each major costs money and energy to NOTHING: just to show that development teams are able to release two versions per year, two versions full of vacuum .

 

We have all been waiting for new accountancy module for 2 years. The time spent to release a new version will have better been employed to work on this strategic module…

 

 

Bien cordialement,

Charlie Benke

 

De : Dolibarr-dev [mailto:[hidden email]=[hidden email]] De la part de Developpement | Open-DSI
Envoyé : mercredi 19 octobre 2016 16:24
À : Posts about Dolibarr ERP & CRM development and coding <[hidden email]>
Cc : [hidden email]
Objet : Re: [Dolibarr-dev] [Dolibarr-association] Dolibarr 4.0.1

 

Hi

Thanks to Camille for pointing the main problem : Module and ratio time spend / bug / patch
As integrator of Dolibarr, it's not "sustainable" for me to test every six month Dolibarr and the modules I'm commonly using. Today I only install 3.9. Maybe next year, I will uprade to 5.0 or not... depending of what functions will be added or remaining experimental.
Modules are too often broken by new version. On the Dolistore you can see module labeled 3.x-4.0 who are in fact broken with the last version or doesn't exist for the current version of Dolibarr. I think it's not good for the reputation of Dolibarr.
I'll be pleased to discuss about this subject in Valence :-)

Regards
Philippe Scoffoni - Open-DSI




Le 19/10/2016 à 15:14, [hidden email] a écrit :

Hi

 

Thanks for sharing this.

I agree, Dolibarr migration is pretty nice !

 

but only core part, modules looks more problematic to update.

 

Regarding communication, this is a work in progress.

 

Yes I saw this :) But looks again difficult. But it's better :)

 

From now on, we'll have systematic annoucement when a major version is released, minor version too, why not. A communication group has been started within the fundation with the goal to better communicate with the community. We already are present on social medias, but this dev mailing-list and the dolistore customers are 2 audiences we poorly communicate with (not to say not at all).

 

I don't understand logic, dolibarr users/community are on forum, mailinglist but piority is social network, strange

 

About your concerns around PRs and plugins, I'm sorry you feel that way. PRs are usually correctly integrated and not lost.

 

Maybe now, I'll try again. But I'm not sure. My fear is to lost again energy to nothing.

 

Plugins are the responsibility of their developers. Personnaly, our plugins are upgraded with the new releases

 

I'm not module developper then I don't know if is complicate or not to follow release and provide. As user, i prefer to have my own script and don't use module. In my use case ratio time spend / bug / patch is too heavy.

Thanks a lot

 

km

 

_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev

 


_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev



 

--

------------------------------------------------------------------------------------

Google+: https://plus.google.com/+LaurentDestailleur-Open-Source-Expert/
Facebook: 
https://www.facebook.com/Destailleur.Laurent

------------------------------------------------------------------------------------

* Dolibarr (Project leader): http://www.dolibarr.org (make a donation for Dolibarr project via Paypal: [hidden email])

* AWStats (Author) : http://awstats.sourceforge.net (make a donation for AWStats project via Paypal: [hidden email])

* AWBot (Author) : http://awbot.sourceforge.net

* CVSChangeLogBuilder (Author) : http://cvschangelogb.sourceforge.net

 

 


_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev



 

--

------------------------------------------------------------------------------------

Google+: https://plus.google.com/+LaurentDestailleur-Open-Source-Expert/
Facebook: 
https://www.facebook.com/Destailleur.Laurent

------------------------------------------------------------------------------------

* Dolibarr (Project leader): http://www.dolibarr.org (make a donation for Dolibarr project via Paypal: [hidden email])

* AWStats (Author) : http://awstats.sourceforge.net (make a donation for AWStats project via Paypal: [hidden email])

* AWBot (Author) : http://awbot.sourceforge.net

* CVSChangeLogBuilder (Author) : http://cvschangelogb.sourceforge.net

 

 


_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev



 

--

Merci d'avance a tous ceux qui vont partager la vidéo dans ma signature ^^

Olivier Geffroy
Consultant Informatique

 

-------------------------------------

Jeffinfo SARL

29 rue de la Gare 59320 Ennetieres en Weppes

[hidden email]
Gsm : 0608632740
Skype : darkj3ff

 


_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Dolibarr-association] Dolibarr 4.0.1

Christophe Battarel

Hello, i agree 100% with Charles !

And for the datatables also ! the result of removing it from the core will be that Charles will deliver it with myList, i will deliver it with prices module, and so on... so the final users (you know, this is the people that use dolibarr) will have plenty of datatables plugin instance on his server... great !


Le 02/11/2016 à 17:36, Charles Benke a écrit :

Hello Again

Dolibarr 4.0.2 just delivered that we speak about freeze (one more time the 5.0 …)

So keep calm and just count

2 month for beta version (November, December) 2 other for the release candidate (Janurary, feburary) and we finaly delivery a 5.0 in march … WE don’t respect the roadmap

SO what will be in this new version ?

-          The suppression of jquery datatables plugin, used by myList and some other additional modules…, just because they made some problems with dolidroid …

 

It's fine to have a roadmap in planning terms (which are not required since the schedule speaks of January and July so it was March and September)

But it would be more important to have a schedule on functionality is added or is removed ...

 

 

 

Bien cordialement,

Charlie Benke

 

De : Dolibarr-dev [[hidden email]] De la part de Olivier Geffroy
Envoyé : jeudi 20 octobre 2016 11:08
À : Posts about Dolibarr ERP & CRM development and coding [hidden email]
Objet : Re: [Dolibarr-dev] [Dolibarr-association] Dolibarr 4.0.1

 

It's depends of the final user 

 

let's says for a company (who use dolibarr) and make less than 100K per month and don't have a lot of externals modules, 2 update per year is easy

 

for a big company 1 update per year is enough and with dolibarr isn't a problem to stay in 3.8 and to migrate in 4.0 and squeeze the 3.9 (for example)

 

my 2 cents

 

2016-10-20 10:58 GMT+02:00 Laurent Destailleur (aka Eldy) <[hidden email]>:

I don't understand. You say "If the major release issued every 6 months was free of bug, stable and did not require another install/update after barely one month to correct the most glaring bugs that will not be dramatic"

 

Every experimented developper know that this argument is the best argument to ask to have more release than 2 per year. And you ask less. So why using an argue to ask more release: The more is the delay between 2 versions, the more is the bug rate on production (that's why more and more project are increasing the release frequency) and difficulty to have a stable version is an exponential of the number of feature added or modified. So your argue is just incomprehensible.

 

I used on production each version, as soon as it is release and announced and I have no problem. Also the stability of a version depends on bugs fixes during the beta period and number of unit tests added when added new future. Developers must work on this direction instead of an "against productive" idea.

 

 



 

 

 

 

 

2016-10-19 21:34 GMT+02:00 Charles Benke <[hidden email]>:

OK

 

If I follow your argumentation … I will deliver a brand new version of all my modules each week, because I have decide to planned like this

Even if the version is not enough tested, even the previous release have some know bug, even if the document are not upgraded …

And I will explain to my disgruntled customers that this is a good method to make a better quality and simplify their upgrade ...

 

Release a version every 6 months because FOR YOU is more simple is not acceptable. I do not develop modules dolibarr because it is easy but because it allows users to better manage their company, create growth, the emploies ...

 

If the major release issued every 6 months was free of bug, stable and did not require another install/update after barely one month to correct the most glaring bugs that will not be dramatic

 

The minimum straightforwardness that we can have with users downloading a new major release is to explain that this version DO NOT BE USED IN PRODUCTION.

 

 

Bien cordialement,

Charlie Benke

 

De : Dolibarr-dev [mailto:[hidden email]=[hidden email]] De la part de Laurent Destailleur (aka Eldy)
Envoyé : mercredi 19 octobre 2016 17:34
À : Posts about Dolibarr ERP & CRM development and coding <[hidden email]>

Objet : Re: [Dolibarr-dev] [Dolibarr-association] Dolibarr 4.0.1

 

Your argue is not coherent.

You say you want less version so you have to test your module less often. It also meas your customer upgrade version less often.

 

So why just don't you make your tests every 2 versions. Result will be same. You will work only every 1 year instead of every 6 month, and your customer would be able to upgrade only every 1 year (once your module is validated for the version) instead of every 6 month.

 

It's just your choice and the choice of your customer.

 

Having a release every 1 year, means nor integrator, nor users have choice. Also it means a lower quality and exponentiel work to make upgrade.

But if you prefer to upgrade your module once per year, just do it. You can, it's just a choice you must do. It is not because there is a new version, that you must upgrade your module. If you prefer to follow a 1 year release, just follow this rythm and ask you customer to follow also this rythm. The only difference is that the ryhtm is defined by you instead of being imposed be a dolibarr low release rythm.

And i think it is better to let integrator to decide their release/upgrade frequency then having this decied/forced by Dolibarr.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

2016-10-19 16:49 GMT+02:00 Charles Benke <[hidden email]>:

Actually I maintain 22 modules, some are simple, some are complex. To test all of them correctly (use all feature, modify doc, …) each time a new major version of Dolibarr is release is more than 2 full weeks long for Romain an me...

During the month a new version comes out, sales of modules on dolistore are halved cut (according to my information it is not related to my modules only).

 

I could do as some others … , just change the version number and wait for my clients put bugs me but I do not find it honest

 

Most integrators with whom I work no longer wish to upgrade versions as there are no major advances between two versions either-called major

The final version of each major costs money and energy to NOTHING: just to show that development teams are able to release two versions per year, two versions full of vacuum .

 

We have all been waiting for new accountancy module for 2 years. The time spent to release a new version will have better been employed to work on this strategic module…

 

 

Bien cordialement,

Charlie Benke

 

De : Dolibarr-dev [mailto:[hidden email]=[hidden email]] De la part de Developpement | Open-DSI
Envoyé : mercredi 19 octobre 2016 16:24
À : Posts about Dolibarr ERP & CRM development and coding <[hidden email]>
Cc : [hidden email]
Objet : Re: [Dolibarr-dev] [Dolibarr-association] Dolibarr 4.0.1

 

Hi

Thanks to Camille for pointing the main problem : Module and ratio time spend / bug / patch
As integrator of Dolibarr, it's not "sustainable" for me to test every six month Dolibarr and the modules I'm commonly using. Today I only install 3.9. Maybe next year, I will uprade to 5.0 or not... depending of what functions will be added or remaining experimental.
Modules are too often broken by new version. On the Dolistore you can see module labeled 3.x-4.0 who are in fact broken with the last version or doesn't exist for the current version of Dolibarr. I think it's not good for the reputation of Dolibarr.
I'll be pleased to discuss about this subject in Valence :-)

Regards
Philippe Scoffoni - Open-DSI




Le 19/10/2016 à 15:14, [hidden email] a écrit :

Hi

 

Thanks for sharing this.

I agree, Dolibarr migration is pretty nice !

 

but only core part, modules looks more problematic to update.

 

Regarding communication, this is a work in progress.

 

Yes I saw this :) But looks again difficult. But it's better :)

 

From now on, we'll have systematic annoucement when a major version is released, minor version too, why not. A communication group has been started within the fundation with the goal to better communicate with the community. We already are present on social medias, but this dev mailing-list and the dolistore customers are 2 audiences we poorly communicate with (not to say not at all).

 

I don't understand logic, dolibarr users/community are on forum, mailinglist but piority is social network, strange

 

About your concerns around PRs and plugins, I'm sorry you feel that way. PRs are usually correctly integrated and not lost.

 

Maybe now, I'll try again. But I'm not sure. My fear is to lost again energy to nothing.

 

Plugins are the responsibility of their developers. Personnaly, our plugins are upgraded with the new releases

 

I'm not module developper then I don't know if is complicate or not to follow release and provide. As user, i prefer to have my own script and don't use module. In my use case ratio time spend / bug / patch is too heavy.

Thanks a lot

 

km

 

_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev

 


_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev



 

--

------------------------------------------------------------------------------------

Google+: https://plus.google.com/+LaurentDestailleur-Open-Source-Expert/
Facebook: 
https://www.facebook.com/Destailleur.Laurent

------------------------------------------------------------------------------------

* Dolibarr (Project leader): http://www.dolibarr.org (make a donation for Dolibarr project via Paypal: [hidden email])

* AWStats (Author) : http://awstats.sourceforge.net (make a donation for AWStats project via Paypal: [hidden email])

* AWBot (Author) : http://awbot.sourceforge.net

* CVSChangeLogBuilder (Author) : http://cvschangelogb.sourceforge.net

 

 


_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev



 

--

------------------------------------------------------------------------------------

Google+: https://plus.google.com/+LaurentDestailleur-Open-Source-Expert/
Facebook: 
https://www.facebook.com/Destailleur.Laurent

------------------------------------------------------------------------------------

* Dolibarr (Project leader): http://www.dolibarr.org (make a donation for Dolibarr project via Paypal: [hidden email])

* AWStats (Author) : http://awstats.sourceforge.net (make a donation for AWStats project via Paypal: [hidden email])

* AWBot (Author) : http://awbot.sourceforge.net

* CVSChangeLogBuilder (Author) : http://cvschangelogb.sourceforge.net

 

 


_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev



 

--

Merci d'avance a tous ceux qui vont partager la vidéo dans ma signature ^^

Olivier Geffroy
Consultant Informatique

 

-------------------------------------

Jeffinfo SARL

29 rue de la Gare 59320 Ennetieres en Weppes

[hidden email]
Gsm : 0608632740
Skype : darkj3ff

 



_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev

--
---------------------------------------
Christophe Battarel
Responsable technique Altairis

+33 (0)9 52 71 70 96
Altairis - Blog - Modules Dolibarr - Twitter
Financez vos projets avec Dolipro




_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
12