Have the Dev's come up an easy way to install the last stable v9?

I am an implementer. And I have a new client that wants to get started right away, but the version 10 ERPNext is not yet stable enough for me to set them up. There is not enough time for me to test it completely and promise them I can make it work. Is there an EASY way for me to setup and install the last ‘stable’ version of v9 ERPNext?

If not, can we make this a developer/foundation request item?

The constant shifting sands of how stable ERPNext is at any given time is not conducive to being able to rely on it as a platform we can implement for clients. I really wouldn’t care if they only make the last major version number (i.e last v9 instance) available as a package. As long as we can continue using what we already know and have thoroughly tested for client systems.

If there is no easy way to do this, then I will be forced to set the new client up with a something like InFlow because it is readily available, stable and cheap enough for a starter system. When ‘time-is-of-the-essence’ it is important to have stable versions that we can rely on to get new customers on-board with open source software.

Most new clients are predictably wary or otherwise afraid of open source software, and convincing them to adopt it as a foundation for their business systems is no small task. That is where we implementers come into the picture. We spend out time teaching potential clients how to evaluate and choose business systems. However, without some stable backstop (such as easy availability of last major version) that we can depend on, it becomes nearly impossible to get new clients to risk their business data to open source systems.We spend our time proving to them how well something works in order to get them to use it. That is nearly impossible when you ONLY have easy access to the most recent release of ERPNext.

Every new release (even point releases) are changing something and many times it is something that affects the user experience. When that occurs, we implementers have to go back and put everything through a rigorous testing process to make sure it dies not adversely impact users. The results of that testing usually shows up in the ERPNext forums as problems that need attention. However, from a user perspective, they cannot afford for their business to be down or adversely impacted by some bug that shows up in a point release. They DEMAND some sort of stability. They DEPEND on implementers like my company to provide that stability by managing whatever version they are using when we set them up.

I know the foundation would like you to believe that customers / users would universally always want the latest and best new features as soon as they can get them. However, the reality is very different. Customers / users really only want something they can depend on to STAY THE SAME for an extended period of time. Your next logical question is WHY? The answer is multi-faceted.

Potential clients are not only concerned about the SETUP COST of implementing a business system. They also have to be concerned about how the system impacts their day to day business processes. This include how a business system may alter how they interact with their own customers, how it affects the people they employ to use the system during their workday, and the processes they must put in place to collect data and use the new insights they gain from their business system. This is only a few of the many things they must consider when choosing a business system.

Clients that adopt a new business system (regardless if it their first system or replacing an older system) are going to invest their money and their time into getting their employees past the initial learning curve of using a new system. They are also going to work out ‘gentle’ ways to change how they interact with their own customers in order to make the most of their new system. Once they are comfortably past those first 2 hurdles, they will really dig into how to use the new insights the system provides to their business. It is not until after they reach this point do they actually feel that they have found value in their new system. Everything up to this point has been a net COST to them. How can we expect them to realistically contend with constant changes to the system when all they would see is additional costs, both financial and time, to re-do everything I just mentioned above?

In fact, there is no way a company with as few as 10 to 25 employees could possibly stay ahead of the learning curve when you look at the current pace of ERPNext development and improvement cycles. To combat this NEGATIVE in potential clients eyes, we need to be able to easily install something we can support without having to depend on the slower pace of the foundation support structure. Clients running a live business cannot wait weeks for something to get fixed, especially when it wasn’t broken at the time they initially started using the system.

Yes… we understand that using older versions means that we will contend with KNOWN problems. The point is, they are in fact ‘known’ problems and we can work with them or around them as long as we know them. We cannot be putting out new fires all the time and still help clients run their businesses.

So, to this end… I need to know if there is yet an EASY way to setup the last point release of the last major version (v9 in this case)?

An easy way meaning possibly a new switch that can be used with the install.py script to setup the last major version (something like: sudo install.py --production --user me --version 9). Or at least something as simple to use as this.

If not, then is this something the foundation is planning to setup very soon?

Of not, then why not?

I we want the user base to expand, we need to start paying attention to the process new users go through to adopt a system.

Right now I need to either setup a v9 system or take my client to some other software. That means that I loose them to the other software for at least 2 years. That is the ROI turn around on their time, training, and financial investments. The time they loose to training and business process changes affects their profitability. To them, time wasted in training and changing processes, is time lost in making money.

So, is there an easy path forward for me on this or not?



I proposed something similar to this at the beginning of 2017 to have two paths similar to how some Linux distros work. E.g keep a version in long term support (LTS) mode while new features and items are added to the newest release. The LTS version (in this case would be v9) would just get security and other “error” updates to it and no new features. The idea is the some organizations are not able to stay totally current, especially if they have customizations to manage and in this case integrators want to work with a known good stable platform for their clients.

I have also asked that we look for stability versus new features. The team keeps adding new features at a huge clip while still leaving out core features in well established modules. Maybe we can look at using the LTS branch to adding stability to the platform and then those fixes can of course make it into the master branch.

Adding features to bench and install.py to be able to work with the older version is also going to be important.



I haven’t got time to reply fully but there is a stable 9.xx branch on master you can use. I think this was mentioned somewhere on the V10 notes

1 Like

Is there a set of instructions on how I could get that to install as a production instance? If so can you point me to those instructions?

I am not a developer or skilled programmer. I just use the install scripts to set ERPNext up for my clients.

Thanks in advance for instruction pointers.


1 Like

From the forum ERPNext Version 10 has been released ! 🎉 🌲 ❄

We have pushed a new branch v9.x.x which will maintain the latest code of version 9.

So, if you don’t want to update to version 10 but want latest code of version 9, you can switch to v9.x.x branch manually for both frappe and erpnext repository. After switching to that branch you can run bench --site migrate from frappe-bench directory.

Hopefully this will get you on the right track … best take a backup first



Thanks for the link to the notes. I went there and asked the original author of that post to point me in the right direction for using that branch to install a fresh v9 system on a blank server. Hopefully he can be of assistance.


I think you can migrate an existing install with this CMD too

1 Like

Yeah. That appears to be what the original post was about in the v10 notes. My problem is different.

I need to be able to install from this branch onto a blank Debian server. I just have no idea how to go about doing that.

For my previous clients, I have always been able to use the install.py script to setup a server and then just lock it down once I had everything in place and working. This time my client wants to start up quickly and I don’t have time to completely test version 10 to make sure nothing is going to bite me in a week or two. That’s why I need to be able to setup a version 9 server. I have already tested it do death and know what I am getting.

I just cannot find any instructions on how to install from anything but the default branch that the install.py script uses.

Hopefully someone will come along that can point me to an information source to help with that.



You pose a good question - for first time learning I tried a ‘manual install’ by doing this:

Step 1) get frappe

frappe@erpnext:~/frappe-bench/apps/frappe$ git branch -a | grep v9.x.x
frappe@erpnext:~/frappe-bench/apps/frappe$ git checkout upstream/v9.x.x
Note: checking out ‘upstream/v9.x.x’.

You are in ‘detached HEAD’ state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

git checkout -b new_branch_name

HEAD is now at 03672a5… Don’t sanitize password (#4681)

Step 2) get erpnext

frappe@erpnext:~/frappe-bench/apps/frappe$ cd …/…/apps/erpnext
frappe@erpnext:~/frappe-bench/apps/erpnext$ git checkout upstream/v9.x.x
Note: checking out ‘upstream/v9.x.x’.

You are in ‘detached HEAD’ state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

git checkout -b new_branch_name

HEAD is now at 537db4c… Merge branch ‘hotfix’
frappe@erpnext:~/frappe-bench/apps/erpnext$ git status
HEAD detached at upstream/v9.x.x
nothing to commit, working directory clean
frappe@erpnext:~/frappe-bench/apps/erpnext$ cd …/…

Step 3) run reinstall on the latest v9 release Releases · frappe/erpnext · GitHub

frappe@erpnext:~/frappe-bench$ bench version
erpnext 9.2.24
frappe 9.2.25

frappe@erpnext:~/frappe-bench$ bench reinstall
This will wipe your database. Are you sure you want to reinstall? [y/N]: y

Installing frappe…
Updating DocTypes for frappe : [========================================]
Updating country info : [========================================]
Set Administrator password:
Re-enter Administrator password:

Installing erpnext…
Updating DocTypes for erpnext : [========================================]
*** Scheduler is enabled ***

Step 4) Sign-in with Administrator password and run Wizard!

I can’t say this is all you need to do but it’s a start…let us know how it goes.


For what its worth:

I keep a fresh snapshot of a clean, not setup ERPNext after every version change. I setup using the install script, and then next thing I do before I touch anything is make a snapshot. Whether it is on on the cloud or on a local setup, it saves a lot of the hassle with this particular problem.

I agree with using a Linux-like release scheme with LTS versions, and periodic upgrades for cutting edge stuff.


Hmm… The problem with your instructions is that you are doing everything from an ‘existing’ erpnext structure. The very first instruction in “get frappe” is executed from and existing frappe directory structure “~/frappe-bench/apps/frappe$” indicates a structure where everything already exists. I need to figure out how to do this from a “blank” server.

Yes. I do this as well although not for every version change. I only do it for a locked down client version in case I even have to rebuild then from the ground up. This is always stored on their production backup server. However, I have no way to transfer one of those to a different hosting company on a blank server. If everything were always on Google Cloud it might be possible, but I am stuck using my clients hosting to get their work done. That is why I need a way to do a v9 install to a blank server.

Really, I am looking for a way to tell install.py to use the v9.z.z branch to run an install (or something that will accomplish the same end result).


1 Like

Thanks for your reply and your concerns BKM -

Yes what I offer must be ‘vetted’ or ‘certified’ as equivalent to a fresh clean install that I do appreciate you require. The Frappe masters are experts here, not me.

That said ‘git checkout’ indeed does replace the former and entire erpnext and frappe directory contents, to a identical code state that matches the tagged branch.

On the other hand precisely what ‘bench reinstall’ does to ‘reinstall the site’ is not clear to me and requires investigation. One big question is what data comes from where in the ‘reinstall’ script. For my learning too I must also study the install process to incorporate what you request.

Thanks, any and all comments are welcome!

Can anyone point to instructions for how to install to a blanks server from the v9.x.x branch?
I still need to be able to do a clean install to a blank Debian server with a v9 ERPNext.

The Install.py script only pulls the most recent v10 stuff.


Here is my $0.02

Follow these steps to get latest installed in a default bench (i would call the bench “trash” because you will delete it once done)


Then follow these steps to setup a side-by-side bench


You will want to alter the get-app command to download erpnext to pull the branch tag you want instead of master.

bench get-app erpnext https://github.com/frappe/erpnext --branch v9.x.x 2>&1 | tee --append ../erpnext-install.log


Hmm… looking through the links, it seems complicated and it looks like the bench and the ERPNext version will be out of sync when I finish (bench and frappe version 10 with ERPNext at V9). Also seems to be designed for developer work, not a production install.

I will give it a try in the morning with a fresh Debian server, but I am not holding out much hope.



FWIW here are test result examples

v9.x.x branch build # 17075 from a run 15 days ago Travis CI - Test and Deploy Your Code with Confidence

master branch build # 17155 on Dec 28 all tests passed Travis CI - Test and Deploy Your Code with Confidence

These build test results may be of interest when to checkout the code.

Thanks John. I did not know such test results postings existed. Based on those postings, it appears that I may be wasting my time trying to get a 9.x.x system running. The build failed it’s last test as per this screenshot:

I cannot imagine that the developers are doing any maintenance to the 9.x.x branch so It does not appear I should waste my time on it any longer.

That really is sad though. That means that I have to start my client up today on a different erp system and step them through buying the licenses, etc. Financially they will not see a difference because what is not spent in licenses with ERPNext, is spent in time to configure such a complex system and work past any current bugs. Whereas with the purchased software, the stable version has been around for a year and I have configured it many times, so ther is no additional learning curve.

I would prefer to keep new clients on ERPNext, but it changes to fast for me to keep up with regression testing, and the developers refuse to make long-term stable release points. I give up!

This new client will get an off-the-shelf ERP system. Hopefully I can get enough testing and configuration work done on ERPNext v10 before my next client wants an installation.

@clarkej Thank you for the heads-up link to the test results. You saved me a ton of time and made me sad at the same time.


Yup. It’s hard to keep up. What we’ve done is the following.

  1. We have our own repos of bench, frappe, and erpnext.
  2. Whenever we setup a new server, we follow the manual installation instructions at Guide: Manual Install ERPNext on Ubuntu 16.xx & Debian v8 & 9 and make sure to use our own repos rather than the official master/dev branches.

If you have another client on v9 and tested, then login to their instance and push bench, frappe, and erpnext to new repos. Then use those repos to install.

The downsides of this approach is we’re often far behind official, and we have to maintain our own “stable” repos. But that’s how we guarantee stability and properly test our internal instances. If you have many clients, that’s pretty much the only way you’re going to be able to guarantee any type of stability. The other downside is once you go down that route, you’ll inevitably run into a client who needs the newest released feature, and you’re either going to have to upgrade them individually (which means you’re now maintaining 2 or more LTS branches)or tell them to wait until all are updated.

I also realize that this isn’t a step-by-step primer of any kind so it’s not quite what you’re looking for. I just don’t have the time to put it together right now or even in the near future. It is possible to run an “LTS” though!


Whoa! I did not even know this was possible. Thank You!! I now have a new idea to research as a solution. Obviously it is too late for the client I had to setup today, but it in the longer terms, it will be useful in the future.

I had also not run across this set of instructions before. (It all has to do with the terms used in search I guess). Hopefully I can get this figured out in time to actually have my own repos for version 10. My only working installation of version 9 is not as up-to-date as I would have liked, so I am not sure it is a good candidate for the push scenario. Besides, I still have to figure out how to even do this kind of ‘push’ stuff and how to setup my own repositories. I need a bit more education on this and it will take some time.

Hmm… I don’t see that as much of a downside really. I already keep snapshots of working instances (without data) for my clients. I save them to the backup servers that I put in place for every install. This way I can always get back to their ground zero and reload data in the event of a catastrophic failure of any type. So maintaining stable repos instead is actually a better solution because it is NOT dependant on the particular hosting service the client is using. For example… if my client is on Google Cloud Platform, I cannot take an imae from there to use on the Amazon Cloud services, or any other hosting company for that matter. But if I had my own repos on a server somewhere, I could always install from them just like the install.py does from the official branches and it would not matter what the hosting company was. This would eliminate the problem of keeping so many different snapshots around (they cost money to store).

Again, I don’t really see this as a big deal. Consider the fact that I am already using off the shelf software when I cannot get access to the old versions of ERPNext. So who really loses in my current scenario? EVERYONE!!! ERPNext Foundation loses because another potential user base is lost for several years to commercial software. The end user client loses (the people I setup on the commercial software), because they are forced into a software package that is not easily expanded or modified to suit their needs and they are stuck that way for at least 2 years before it is worthwhile to change business systems again. The implementer (like myself and my company) loses because they are forced to support software from multiple companies in order to help their clients setup ERP systems and manage their businesses.

What an eye opener this has been. Thank you @felix for some insight that I did not have and did not know was possible.

I am loathe to promote ideas that go against the foundations goals, but I also cannot support the foundation when they choose to ignore such an important function as long term stable release points. Something needs to change if ERPNext is to make it out of adolescence and into the real world of business systems.



There are some great points here.

How about creating a fork and maintain a public stable v8 or v9? It doesn’t have to go against the foundation but just a stable version for people to use.

When it comes to users and businesses stability is far more critical than being cutting edge. Not saying we don’t want improvements but the effort to “keep up with the Jones’s” is taxing. Upgrading should be worth it. Example : a cutting edge manufacturing might be worth the hassle going from v8 to v10.

If you guys are already maintaining a sort of LTS version, perhaps share? :slight_smile: thanks

In the end if we want it real bad, we gotta make it happen!

1 Like