Dear All,
I am referring to my previous post yesterday, where I highlighted the plights of many users (yes, I did search the forum and beyond!) when upgrading ERPNext. Secure and functional upgrade paths are absolutely essential and should not be up to experimentation by users, multiple errors and insecurity, especially if no custom modules have been deployed.
I repeat: THIS IS A MUST, UNNEGOTIABLE, if (IF!) ERPNext wishes to continue to attract users that entrust this otherwise terrific software their valuable data.
I have been called an impolite troll, which is quite cute, but insist on not only having a point, but the moral duty to highlight this severe shortcoming of the software.
Thank you for another user’s valuable hints on always making backups and mirrors, etc. Appreciated. I am a pretty experienced user in a number of regards, and when I talk of data loss, I refer to data loss during upgrade attempts. Not absolute data losses.
Still, not good. Users get, without a safe upgrade path, locked into an old version that will become obsolete sooner or later, and all their work is in vain. There is indeed a moral duty (even if there is no contract - it is a simple matter of QC and (encouraged) documentation within the supporting community. And a matter of following up on issues and bugs. There have been lapses, and I can, at this pint, only regard the upgrade process as highly brittle.
If an urgent call for action is impolite, yes, it may be. It is, however, an equally “impolite” (irresponsilbe?) undertaking not to tell users that there is - not yet, and in contrast to other ERP systems, a safe upgrade path. I insist that this is, in the view of the massive amount of work that users put into ERPNext, utterly unacceptable. Call it trolling, if you like. If you think so, please reomve me form this user list. Now.
Much appreciated.
Chris
Bud here are few quick points:
-
Common sense that you don’t update live system directly. You either
- Take a complete snapshot backup of your system, and work on the live system with confidence that if things goes wrong then you can restore the snapshot with one click.
- The more appropriate way is: take a snapshot of your live system and experiment update on the snapshot in your test environment, then when you fully satisfied, you move forward by updating live system while also ensuring you have a backup.
-
You are not updating your simple peace of software here, you are updating a complicated ERP system with a sophisticated database structure. Between updates the team adds patches to update the data base schemas, so when you delay updates to multiple versions you are accumulating patches where update errors will be most likely.
-
You are using open source GPLv3 licence software, so go read the licence to understand the liability in the licence.
-
You are hosting your system by your own, so you are also on your on when things go wrong, because bud any system administrator with minimalist training will know that what you did is huge mistake and redflag.
-
Finally and more importantly we are here as a community and we help each other as a community, you are not paying our salary or putting food on our tables, so we owe you nothing. So be respectful to yourself and others, which you weren’t in your last post.
If you don’t know or don’t have a training to manage your server, then hire someone to do it for you or get subscription from a host, then you can get mad at them when things go wrong.
On top of what @ganas wrote, please take a look at example of how similar case can be discussed and worked out: Performance Upgrade, moving slowing install to v9.
Why not to share particular error logs so we can help on the matter?
@chlarsen Did you get the update working? Lets know where you are with that, maybe we can assist you complete it.
Thanks for the feedback.
I assure you, I know what I am doing :-D. Nobody is perfect, but I know a fair bit about somplex system administration, databases and running Python in various frameworks. Of course, you utterly reasonable suggestions on backups, test versus production instances, etc. are entirely justified.
What I am getting at is something different: Upgrade have to be smooth. Tested ad nauseam, before new releases are made, even more so, if the application contains huge amounts of critical data.
Look at operating system updates, dataase updates ad, yes, other ERP updates. They can be a joke (as in “Please send us your database and we will upgrade it for you to the next version” à la Odoo - down go confidential data and, of course, anf concept of libre), or as smooth as silk à la Tryton, just to name a few.
No question, which aporach is preferred here :-).
I am not sure whether it is actually worth my while to pursue with ERPNext, because apart from the grave not-at-all smooth upgrade and even new installation issues, there is an increasing number of costed “Industry versions” that drive a dual-licensing approach. I consider dual licensing a mid- to long-term trap that undermines the free/libre and open-source idea. So, a double worry.
Your help has been appreciated, but unless I get a crystal clear commitment to free/libre and opoen source (for self-hosted deployment) and a working upgrade path, this is way too risky a commitment.
Thank you.
Chris
Before you say how things have to be, you have a duty to yourself to keep your software patched up, regularly. That’s your duty. To yourself actually. Frankly no one cares if you didn’t.
Youn leave the movie when it running for a cigarette break and come back ages later and expect some one to fill you in.
No one owes you a “flawless upgrade path”, not even a poorly written broken path for that matter. This is a community.
Your kitchen is your responsibility. Everyone has to keep up thier own duties before they will bother about your mess.
You contradict yourself. If the upgrade path is a mess, you try to do it only if absolutely necessary.
Enough of it, I am out. Good luck.
Good luck to you too!