The technical term is Nondeterministic. For the same inputs (ERPNext Version/Build), we are getting different results. For a production/live environment, you never want this to happen.
To avoid this, you must ensure that your environment conditions are 100% repeatable. Never install/clone software using “latest” or “stable”. Use precise version numbers. For example:
Assume that @BKM and myself have exact copies of ERPNext v10 + Database.
He installs his today, February 18th. Bench fetches the latest, stable version of MariaDB, 10.3.11 Stable.
I install mine, February 24th. Bench fetches a newer, stable version of MariaDB, 10.3.14 Stable
It is possible that our 2 ERPNext could behave differently! One of us could experience bugs.
Why? Yes, we’re both using “stable” MariaDB. But we have slightly different versions. In a production environment, you never want to download a random, latest stable version of software.
Docker containers are 1 tool that can help solve this. Because each container stands alone, independent of the host. My MariaDB Docker container 10.3.12 will be the same today, tomorrow, or 5 years from now. (just make sure your Dockerfile isn’t written to download nondeterministic versions of its own dependencies ! )
So. What needs to change from us? When we release ERPNext Version #?. It should be released for a specific Python, MariaDB, Redis, Nginx, Node.js, etc.
Otherwise, you will never get the same results. Which is why there are hundreds/thousands of posts on these forums, with people having Installation problems. The installation of ERPNext is currently NonDeterministic.
Just to be clear. I am not saying that all ERPNext users must deploy identical environments. I love the flexibility of ERPNext, and that we can run it in dozens or hundreds of different environments.
But regarding LTS, then yes. You must target specific software/environment builds and versions. Otherwise it won’t really be stable.
This may also explain why there are some people on the forum that report problems that get critical ‘snubs’ from other ‘experts’ because the expert cannot replicate the issue simply because their sources may be slightly different from the newbie’s installation even though the erpnext and frappe version numbers match.
It is the one factor that has annoyed me to no end about how some error reports are treated here.
so, would it be ideal then that the installation descriptions (incl. the install.py) would refer to exact version rather then ‘stable’? This (once the mindset is put on this matter to be of importance, which may be simple or difficult) should technically be doable easily.
And if that would solve the problem you and BKM are describing here, should be made a goal achieving.
Exactly. They should refer to specific versions. Which versions to use? The same versions used during LTS stability and regression testing…
Of course, this now leads to a new set of questions:
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.
Time for us to open our favorite word processor, and get typing.
As for the second question. It would be easy to just say “the maintainers are responsible”. But I don’t think that’s fair. Instead, there should be team of volunteers. The ERPNext LTS Group, who are responsible for performing all the testing, and “signing off” on an LTS version. They would choose the environment/versions used during the process.
being that I’ve been doing a lot of work on the official docker image, I think making package installs stable will be the next thing I work on after getting docker stack to run successfully.
UPDATE: changed my mind, it’s the next thing on the list!
As a general principle, from Version 10 onwards, we plan to support each major version for at least 3 years from date of release. The reason for this is that companies that have significant customization on top of ERPNext should be not be forced to move to new releases immediately.
For contributors, this means that separate pull requests for bug fixes and security fixes must be sent for each of the supported versions.
Here is the support plan for major versions that are being supported now:
Version
Branch
EOL
10
v10.x.x.
End of 2020
11
master
End of 2021
12
develop
Not Yet Released
Note: Fixes to Version 10 will not automatically be merged in Version 11, and so on.
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’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:
Allow the user to drag-and-drop to re-position the boxes, everywhere. Sectional contraints can be applied.
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.
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.
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.
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.
