A general comment on versions, design and architecture changes

[bkm]

Thanks @salman

I was not aware this information was listed anywhere yet.

I was hoping for something a little longer support time. However, at this point, I am happy to have some level of version stability.

Most people that want to have a stable version will be installing the last v10 knowing that it will not change while they are using it. This make it much easier to avoid v11 and all of the constant changes that are happening there. Even though it has been called ‘stable’ the reality is that bug fixes for one item sometimes tend to inject new behavour in another part of the module.

For example… with all the current reported buginess in the new permissions functions, if you come up with a work-around for your particular permission problem, any fixes to how permissions work (to fix the root cause of the bug) could very well render your work-around broken on the next bench update.

There will be many cases like this as all the fixes get implemented into v11 over then next year or so. Trying to use v11 as a stable platform is not yet a reality when you take these kinds of fixes into account. Certainly there will be no ‘new’ features added to v11, but the bug fixes alone will be enough to keep a lot of operators away from it until it much further along.

My only 2 ventures into using v11 as a possible launching platform for 2 new clients, both blew up in my face due to the permissions bugs keeping me from properly setting up lower level users to perform important functions. So I had to make all users “System Managers” in order to get most stuff working efficiently for the 2 week demo trials, only to have the constant nag screens asking any “System Manager” and Administrator to perform updates. By the time I found someone that could give me a way to stop the nag screens I had already lost enough credibility with the clients that they ask me to terminate the trials early and not bother with quotations for business.

So, lesson learned! I am only going to use the stable final releases for my production work. Now that there are published EOL dates, I can better plan new installations almost like any other production software.

I like this. I am happy about this.

BKM

[vrms]

@bkm

I like this. I am happy about this.

even though we are happy if you are happy this should not be the end of it yet.
Our mission is not yet accomplished

@brian_pond

• How is LTS approval testing being performed? What are the steps?
• By who?

The first question deserves a formal document. To describe the processes & procedures that allow us to formally label a version as LTS.

@vrms

Let’s use this for developing such. I’d say once we’re done it’ll be put into the core or maybe somewhere under the Foundations wings

GitHub

vrms/erpnext_lts-cookbook

this repo is created to create formal document to describe the processes & procedures that allow us to formally label a previous ERPNext version as LTS - vrms/erpnext_lts-cookbook

[bkm]

@vrms

even though we are happy if you are happy this should not be the end of it yet.
Our mission is not yet accomplished

Point taken. Thank you. I back your ideals for making a more formalized (and documented) approach to the process.

BKM

[adam26d]

@rmehta

Extending the thread here for a general comment: A General Comment on Versions, Design and Architecture Changes

Hope this is a good place to post this.

I’ve spun out a v12 site, testing out the new UI. I must mention it’s quite refreshing. After my experience, I personally feel users might feel less “overwhelmed” which is a big plus. I’ll test this out on new users. If I could change something it’d be:

1. Allow the user to drag-and-drop to re-position the boxes, everywhere. Sectional contraints can be applied.
2. Allow users / the admin to hide some of the modules and menu items [by default]. Admins should be able to reduce features to only what is needed for a user / user group, giving ERPNext a clean and easy feel.
3. Allow users to add a background image. Some people here had beautiful desk backgrounds, they’ll feel way more at home.

Note to the community: if anyone feels off about the changing navigation in v12, give it a spin and see how you feel after.

Edit: Another concern I had was how this would look on mobile. It’s not Icon based but works pretty well. If one uses the PC version, the mobile version will quickly be familiar.

[rahy]

@bkm

By the time I found someone that could give me a way to stop the nag screens

If I may ask, how do you do this?
Thanks

[bkm]

@rahy

If I may ask, how do you do this?
Thanks

Read this:

[FYI] How to turn off Update Nag Screens in both v10 and v11

Recently I tried using v11 for a client demonstration and found the constant nag screens (New Updates are available pop-up window) kept derailing my demo. So I asked the question about how to turn off those pop-up nag screens. There was a lot of ‘push-back’ against doing this in my PM’s and direct emails, but I really needed to do this no matter the supposed problems. If you are facing a similar problem, I found there is a way to do this, but it requires editing 2 important files in the system. …

BKM

[crafter]

@bkm

You may have an image file you could restore on one of the original service providers servers but it rarely would be compatible with a different provider (even if they would agree to allow the restore).

At this point you have no way to re-install the same version and get back online with your work. Your only option is to install whatever the newest version is that works with the install script. Then you must deal with the headache of trying to get everything working again when there were changes made to the core.

Never, ever under estimate the value of a good backup/restore strategy.

Additionally, rather than blame the software, look at your change control process.

[bkm]

@crafter

Never, ever under estimate the value of a good backup/restore strategy.

Additionally, rather than blame the software, look at your change control process.

Now that is laughable!!

People using ERPNext do not have control over the “change control process” because the dev team releases changes as they see fit. The best one can do is spin up whatever version is available at the time they do their installation and then make an image backup of it. That is the only way to ‘freeze’ your version. Even trying to install the exact same version the very next day my result in significant differences because the install process simply calls for whatever the available versions are of the supporting packages at the time of installation.So, if git, or pip, or mariadb, or any of the multitude of other supporting packages changed even slightly, then your second install will be different form the day before.

There is no backup/restore strategy that will fix the constant flux of changes aside from the image backup. The only problem with image backups is that they are not usually very portable. They typically only work on the same VPS service provider. I have even experienced the incompatibility problem one the same service provider when they changed their standard offerings in order to keep up with competing service providers.

This is not like some MS Windows program that has everything needed ot compete an install built into the install cab file. This is more of a live install process where all of your install elements are subject to change at any time and you cannot possibly control for that unless you alter the install process itself to only pull from sources that are fixed to never change.

The average ERPNext user / adopter does not have the ability to alter that process.

So again, we do not have enough control over the change control process in order to compensate for these issues. That is why you will find several voices ‘blaming’ the software for not providing reasonable methods of installing the same version repeatably. This is why there is also a lot of threads asking for LTS versions to become standard.

BKM

[peterg]

@bkm

The best one can do is spin up whatever version is available at the time they do their installation and then make an image backup of it.

Anybody running a production site should be making regular backups, entirely separate from VPS images. I’ve never had a problem restoring from a tarball and a database dump.

[bkm]

@peterg

Anybody running a production site should be making regular backups, entirely separate from VPS images. I’ve never had a problem restoring from a tarball and a database dump.

Do you mind sharing what directories exactly you include in the tarball you make of a running production system? I would be willing to give this a try if I knew what should go into it.

BKM

[peterg]

It was about six weeks ago last time I tried it, but I believe it was just the entire frappe-bench directory. There were a few extra steps, like relinking nginx.conf, but all pretty straightforward as I recall.

[bkm]

@peterg

There were a few extra steps, like relinking nginx.conf, but all pretty straightforward as I recall.

So did you have to install python, nginx and mariadb before you unzipped the tarball or were you restoring the tarball to a server that had already once been an erpnext server?

BKM

[peterg]

It was a clean server, and then I installed frappe’s dependencies like normal. I can’t recall my steps exactly, but I suspect you could just follow the standard manual installation instructions and then just stop at the bench new-site command. I’m happy to discuss more, but it’s probably worth doing it in a new thread. Feel free pull me in if you start one.

[crafter]

@bkm

This is not like some MS Windows program that has everything needed ot compete an install built into the install cab file. This is more of a live install process where all of your install elements are subject to change at any time and you cannot possibly control for that unless you alter the install process itself to only pull from sources that are fixed to never change.

ERPNext is not a desktop application. It is an enterprise ERP system, which has many moving parts which work together.

From what I gather, you are installing ERPNext on behalf of your client. It would then be expected of you to manage the change.

A good change control process will document
=> pre-conditions and pre-requisites
=> the upgrade process
=> backup and recovery process
=> back out process

You cannot expect to cut and paste commands and hope it works. Often for production software, a beta system is required. You would be expected for major changes at least to perform the upgrade on a beta system. We are a small manufacturer and have both a beta system and production system. Because we understand the value of constant updates and the nature of the ERPNext system releases, we see it fit to manage upgrades in this way.

[crafter]

@bkm

Do you mind sharing what directories exactly you include in the tarball you make of a running production system? I would be willing to give this a try if I knew what should go into it.

Have a look here.

erpnext_admin_guide

This helped me to get going. There may have been some minor changes here and there from the docs, but it was a good starting point.

[bkm]

@crafter

A good change control process will document
=> pre-conditions and pre-requisites
=> the upgrade process
=> backup and recovery process
=> back out process

Exactly! I do this with clients already. The problem is how to save them in the event of a server failure. I already have methods in place to make frequent backups of the databases and supporting files.

The problem is being able to replace the installed program with the exact same version the users were running before the failure. THIS is where I find the difficulty.

The only successful approach I have found is to have a complete image backup that I can have restored to a brand new server when there is a failure. This is because there is actually no effective way to re-install ERPNext to a point version that the users were on before the failure event.

Someone here suggested making a tarball from the frappe-bench bench directory and unzipping it to a new server then restoring the database and the support files. However, when I tried this in the past I could not get the server to work. Important pieces are not residing in the frapp-bench directory like the mariadb programs, and nginx, etc. Hopefully someone that has been successful with the tarball approach can elaborate a little on how to get it working.

However, up to this point I have not heard of anyone that can for example install a v10.0.14 version of ERPNExt on a fresh server and then restore their backups. For that matter it is not reliable to try to install the last supported version of v10 and expect that it will be identical to the same installation a week later due to the constant changes happening in all of the supporting packages.

This is why I compared it to NOT being like a MS Windows package. I have installed many MS Windows Server 2016 packages where everything is built into the cab files that are used to do the install. Doing it this way gives you the exact same install every time not matter if it is this week, next week, or next year, the server will just work! So no I am not comparing some simple desktop install to a server install.

@crafter

You cannot expect to cut and paste commands and hope it works. Often for production software, a beta system is required. You would be expected for major changes at least to perform the upgrade on a beta system.

Exactly again!!

I take it a step further and freeze the production server at whatever point revision it is when it goes live and I do NOT allow any updates for 2 to 3 years. I provide a live production server, a ‘sandbox’ server for users to practice how they use the system, and 1 or 2 hot spare servers that are automatically updated every hour with fresh database and support file backups.

In this case I do not need a ‘beta’ server because I do not allow upgrades anyway. All I care about is being able to replace any one of the servers with a fresh one in the event there is a hardware failure at the server farm. THIS is all I am referring to when I decry the inability to make a fresh copy of an older server (even if it is supposedly still a supported version).

Currently I have one configuration where the primary live production server is in New York. The same day I created it, I also took an image backup of it and restored it to identical servers in New Jersey, Chicago, and Los Angeles. This gave me a production server and 3 possible hot spare backups. One day last year the primary live production server in New York failed and all information was lost and unrecoverable. No problem, I just switched the users to the New Jersey server and kept on going.

The problem came around when I tried to replace the bad New York server with another one configured exactly the same way. Since the time I created the original servers the VPS service provider changed their standard configuration to include a little more memory and a little less disk space but moved to SSD drives. Now my image backup will not restore to the servers of the new configuration due to the disk size differences and I have no way to get back a replacement server for the dead one. The great techs at the service provider tried everything they could think of and could not get a restore process to work.

Now the question is how do I re-create another server with the exact same version of the software? So far, I cannot. This is the problem I have been search an answer for and not whatever everyone else has been reading into my posts.

@crafter

Because we understand the value of constant updates and the nature of the ERPNext system releases, we see it fit to manage upgraded in this way.

I am happy that you find value in the constant updates to ERPNext. Your experience is exactly the opposite of mine in this respect. I have not found a single user base that was comfortable with interrupting their users to teach them new ways they might have to use their software each time it changes. Changes to them cause work slow downs and impede their revenue flow. This is why they all choose to have wither 2 year freezes or 3 year freezes on version changes when they sign with me. Almost all of them have had the terrible experience of upgrading versions frequently of other software and specifically want a guarantee that they will be protected from that situation for a fixed period of time.

BKM

[bkm]

@crafter

his helped me to get going. There may have been some minor changes here and there from the docs, but it was a good starting point.

Thank you for the link. I will try to digest this over the coming weekend and see if I can get your tarball approach to work.

BKM

[bkm]

@peterg

It was a clean server, and then I installed frappe’s dependencies like normal. I can’t recall my steps exactly, but I suspect you could just follow the standard manual installation instructions and then just stop at the bench new-site command. I’m happy to discuss more, but it’s probably worth doing it in a new thread. Feel free pull me in if you start one.

Thank you!! I will do some experimenting with this and may setup another thread is I get stuck. I have a rainy weekend ahead to sit at the terminal and work on this.

BKM

[chabad360]

@bkm

The problem is being able to replace the installed program with the exact same version the users were running before the failure. THIS is where I find the difficulty.

And this is why docker images are so useful! They work so far in docker compose environment (last I remember) but I’m actively (well, I had to take a break because of school, but I’ll be on it from the beginning of next week) working on getting docker swarm to work with it so hopefully we’ll see results soon.

[vrms]

@bkm

we do not have enough control over the change control process in order to compensate for these issues. That is why you will find several voices ‘blaming’ the software for not providing reasonable methods of installing the same version repeatably. This is why there is also a lot of threads asking for LTS versions to become standard.

I guess more control of that sort only comes with more contributions into the core code (which I admit is a bit of a chicken-and-egg sort of situation). Also the way the maintenance is structured currently you could not really say even whether there would be any automatism in such an equation. The maintainers (I believe 100% Frappe PvT employees [correct me whether I am wrong in this please]) have a focus on what is best for the erpnext.com product. Naturally this may not automatically be best for anybody else.