it’s still “just” a Proposal 
.
I guess it would be a good moment for members of the Community (service providers may be one group which benefits significantly from this) to come forward with some sort of commitment to help with the maintenance of these legacy branches.
Yes that is the tough untenable part - for example in math terms there are two sides to any equation, in business legalese there has to be valuable consideration.
Moreover any exchange between parties has to be a defined, reasonable and equitable, for example a contractual agreement . In the FOSS world any such concepts, and terms and conditions, are not specified (that I am aware).
Hence Frappe’s kind offers of commitment to time and effort do not equate or translate to entitlement by users. (I don’t want to sound cynical here.)
@rmehta - How can we help with this?
Does anyone feel changes to Bench would be helpful? So that users can more-easily control their versions?
Even if changes to Bench are not required. Let’s make certain there’s an official HowTo for installing a specific version, changing versions, etc. Let’s make it easy(er)
Well… it is really only a start. It only addresses part of the problem.
Nowhere in his community address on version stability did he address the ability to re-install on a fresh server one of the supported legacy versions.
This is really one of the defining failures of the current system. If you have installed this on a VPS server and something happens to the VPS service provider, you are stuck.
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.
I suffered through this once already and had a perturbed client that spread negative karma about the un-reliability of the system (that it couldn’t eeven get back to where it was when it crashed). Those negative words cost me 2 demo appointments that decided they had no further interest in ERPNext. That was probably the most disappointing results of the whole incident.
There are several threads on the forum about re-installing a previous version and all of them are far more technical than the average person setting up the system can understand. I even paid a developer to try to figure this out for me and they could make it work either. The most disappointing money I have ever spent on this project.
So, if the team wants to be really serious about making stable versions for 2, 3, or 4, years, then this has to be part of the process. Just running “bench update” only works when the server has not crashed. The definition of having a stable version MUST include the ability to install that stable version from scratch without being an advanced developer. It has to be as simple as installing the Ubuntu 16.04 LTS.
Then, and only then can you really claim to have stable long term versions.
I do not believe that frappe and erpnext are currently structured to allow for such a bold plan. I really believe that it will not be possible until the method for installing a system is over-hauled to allow for this kind of action. It would mean a completely different way of organizing the sources.
I like the idea that this is finally on the radar screens of the people running the project. But, please, don’t do this half-way. plan for it and do it right. Maybe start something like this with version 12 or even 13. Just make sure the way the project is structured will support this great idea. I would hate to see it create even more chaos.
I don’t mind being patient and waiting for it, as long as it is done right.
So, thank you for paying attention to the direction of the user base. Thank you for adding version stability to your future plans. We will all be grateful when it arrives, as long as it works similar to all other software that has LTS support points.
/rant off
BKM
With backups and documentation (especially the particular versions of prerequisite software) you should be able to restore ERPNext, no matter what. Should not necessarily even need Bench to accomplish this.
That said, I agree that backup/restore process can be very technical. And made more challenging, because ERPNext can be installed in so many different configurations:
I’m certain people are running ERPNext in ways we’ve never even heard about (I’m looking at you, Raspberry Pi enthusiasts!)
How much of DevOps responsibility falls on ERPNext? How much on service providers? How much on customers/users themselves? I don’t know. But it’s something to think about.
I agree with @bkm , that this needs to be given more thought/effort.
wouldn’t you just have to do an installation with the v10.x.x branch in order to get a fresh v10 installation?
probably at this point in time it would have to be a manual installation, so you can select the desired branch (or is there a flag that’d work with the install.py script)? I guess these are one of the questions which have to be ironed out (and where also the integrators may be one of the groups that might have a big interest in contributing to such practicalities).
the erpnext-docker-debian project by @pipech may be an easy way (once one get’s over the hurdle to sufficiently familiarize oneself with using docker) for getting legacy/LTS versions running
one could get the idea of creating an LXD/LXC image with those legacy/LTS versions which then could be spun up pretty quickly.
I this the possibilities are numerous and we’d just have to focus on one or 2 options and maintain those well. This can be going via Frappe Pvt. or from within the Community (where I could imaging the Foundation could provide infrastructure for hosting images i.e.)
I think a one deal could be … Frappe Pvt. maintaining the code, the community maintaining the easy installation/deployments schemes (install.py, docker, LXC/LXD image)
Maybe?!?
I know that I couldn’t get it to work and I paid a developer to try and they couldn’t get me a stable set of instructions to install a previous version.
When I say previous version, I mean v10.1.14 and not the final version when it was closed out.
A good step by step set of instructions would be helpful so people like me can follow them easily to install a version.
Now… I will say that I agree that really the only version one should support in this way would be the last release of a major version. So, maybe my particular instance was more difficult because of trying to secure the correct version of bench within a major version. It just proven impossible for myself and those that I hired.
Maybe a separate script called “install.10x.py” would be a better approach. There are some folks that are just handy enough to run the install script and will be lost in all of the “branches” talk. I am one!
I do like the idea of a docker solution though. It might simplify things some since the version package can just be downloaded as a single file and spun up fairly easily.
I currently do not know how to work with Docker images, but I am not afraid to figure it out. It is just linux setup stuff (I presume).
Thanks to @brian_pond for the ideas around how to possibly support this as well.
BKM
All great ideas, all it now needs is someone to take charge and deliver 
Really? That is very surprising to me. Do you know what the problem was?
Out of curiosity, I just tested it now, and I was able to get a new site running on an arbitrary release with no difficulty at all. It’s just a matter of telling your local git repo for both apps which commit you want to checkout (using a command like git checkout tags/v10.1.80, or whatever release you’re looking for).
Happy to elaborate more in a new thread if it’d be helpful.
Can you say more about what kind of community support you’re looking for on this, and more specifically how the relationship would work?
This has been thrown around multiple times, will add it again: Contribution Guidelines · frappe/erpnext Wiki · GitHub
I’ve seen that page. It describes how to organize a pull request. I was under the impression that you were looking for more sustained organizational support in some form or another, but perhaps I misunderstood.
From what I was told…
There was a significant change in “bench” sometime shortly after 10.1.14 and getting something to install prior to the ‘significant change’ creates a system that breaks when you restore your database to it.
Evidently there was something about one of the sources that was depricated and no longer supported, but the change to some replacement source created the incompatibility because the old sources were no longer available.
This is nothing new. It happens during the course of developing a project. The only way to make it work is to fork the sources when you are running a project so they do not disappear on you.
This is the Achilles Heel of the ERPNext project. It depends on its sources to remain stable. If something changes, you would no longer be able to install your version. The install.py and the playbook go to the components sources every time you do an install. So, if one changes, your installs will no longer work. It is a constant maintenance effort to keep the installation working.
This is why there is no easy way to currently create stable installation points for old versions. Nobody is paying attention to the changes in the sources that might affect the older versions. The longer the time after a version is closed, the less likely you will be to get a successful install.
I believe this is why the idea of using docker images was put forth as a method of keeping older versions available in some stable format. Once the image is created, there is no longer a need to go back to the original sources.
Anyway… that is the understanding of the situation that I was given for the low, low price of a bunch of paid developer hours.
It is also why I am so passionate about the LTS version thing. Been there, spent the money, and no result.
BKM
^ Exactly this.
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:
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.
/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.