From: Pak R. <pak...@gm...> - 2016-08-01 03:11:36
|
Hi all: A bit off-topic but, here comes my 2-cents. Most of us (I guess) end up with customised versions, to adapt webERP to our real environment and needs. I personally commit into the project all the modifications, customisation, etc that can be good for general use, but some of them too specific due to local legal regulations, or very custom ways to do certain things are kept in my private webERP. I guess most of us follow roughly the same standards. Life managing and merging "my" webERP with SVN was a nightmare and full of errors until I started working with GIT (thanks Tim!). Since then all merges are almost automatically managed and GIT points out where there are potential conficts and can be solved quite easily. I keep my repository in bitbucket.com and manage it with SourceTree software. I only wished I started using it few years before. So, I do not think we should stop, cancel or delay any improvements just because of the customised versions, as we could end up paralyzed. If it's good for webERP and we can do it, I think we should move ahead Probably most of you already work with GIT, so this email is pointless, but otherwise I think it's worth exploring it. Your merge life can be extremely simple Regards, Ricard 2016-08-01 9:58 GMT+08:00 Rafael Chacón <raf...@gm...>: > Hi Exson, > > Yes, I understand you. We also have customised versions (e.g. we use paper > size "letter" instead of "A4", so every time one printing script is > modified, we have to merge those changes in our scripts). > > As you probably could see, I prefer to make the changes gradually as we > fix or develop code. > > Probably the best way is to modify all the scripts at the same time. That > will generate a lot of work at that time, but it is supposed to not have to > go back to merge these improvements in the future. > > That might be the way to: eliminate the use of ~/includes/class.pdf.php, > replace webERP code with new PHP functions (only those that have more than > 36 months old, e.g. calendar functions), update the css classes (e.g. > ".text-center" instead our ".centre" class). > > Personally, I do not like the idea of the massive changes. Although they > may be simple, these changes make hard the search of bug sources because > they introduce versions no related with the error. > > It occurs to me that we could do a "census" of customised versions and try > to include these changes in the major version of webERP. Thus: (1) there > would no need to merge changes;(2) the webERP is enriched with new options > to meet needs that currently does not. Comments ? > > Best regards, Rafael > > 2016-07-30 19:52 GMT-06:00 ExsonQu <hex...@gm...>: > >> *Hi, Rafael,* >> >> Thank you for your explanation. >> I think currently the problem is not technical issue. It's >> about keep alignment within the application. And as I point out, there are >> lots of users have kept their own version, but when we just change dot to >> comma, it does no change actually for them, but the code seems changed a >> lot. It make them hard to maintain and update. >> So I suggest at least NOT change code with dot to comma >> unless you develop some new code. >> Thanks and best regards! >> Exson >> >> >> >> >> -- >> View this message in context: >> http://weberp-accounting.1478800.n4.nabble.com/Should-we-use-dot-instead-of-comma-as-concatenation-operator-tp4658639p4658646.html >> Sent from the web-ERP-developers mailing list archive at Nabble.com. >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Web-erp-developers mailing list >> Web...@li... >> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >> > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers > > |