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.
/rant off 
BKM
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:
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.
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
This just caught my attention on Twitter. Excellent timing. This article is extremely relevant to our discussion, so thought I’d share with you all.
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!
Um, yes.
I make a PR there every so often with some new features or fixes.
From frappe/erpnext/wiki/Supported-Versions page ,
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.
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
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
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:
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.
If I may ask, how do you do this?
Thanks
Read this:
BKM 
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
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