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

clarkej · January 4, 2018, 11:19pm

Hi BKM,

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
remotes/upstream/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.

Tropicalrambler · January 5, 2018, 2:34am

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.

bkm · January 5, 2018, 4:13pm

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).

BKM

clarkej · January 5, 2018, 9:52pm

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!

bkm · January 8, 2018, 5:08pm

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.

BKM

James_Robertson · January 8, 2018, 10:25pm

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)

https://jwrober.github.io/erpnext_admin_guide/i-u-b/install

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

https://jwrober.github.io/erpnext_admin_guide/i-u-b/install-dev

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

bkm · January 9, 2018, 1:51am

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.

Thanks

BKM

clarkej · January 9, 2018, 4:20am

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.

bkm · January 9, 2018, 12:24pm

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.

BKM

felix · January 9, 2018, 1:15pm

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

We have our own repos of bench, frappe, and erpnext.
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!

bkm · January 9, 2018, 7:35pm

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.

BKM

Not_a_countant · January 9, 2018, 9:01pm

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? thanks

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

bkm · January 9, 2018, 9:37pm

Ohhh my… This cannot be stated often enough or LOUD ENOUGH

Having a stable point of reference is critical to REAL businesses. ERPNext is just not grown up enough to be a real contender yet. It takes stability to be a contender.

Just so you know… (and as a real world example) I recently had to compete with the commercial software SAP. They have developed a small business edition that is stable and a bit friendlier to setup and use than their big enterprise stuff. Even though their price point was more than triple (3X) what I was going to setup with ERPNext, they went with SAP. Why you ask!?!

Simple… SAP has a ready set of documents that can be presented to show ISO9000, 9001, 9002 certification. They have their test procedures documented and in an acceptable format for clients that require that kind of data. This client was a manufacturer with about $11 million in top line receipts each year.

I routinely perform tons of regression testing in order to have equivalent docs ready for my clients, but I could not work fast enough to have them ready for version 9. The version was already advanced to version 10 before I finished testing. Testing and documenting everything takes at least 4 to 6 months of someones time (full time) and I never had a chance to finish with the rapid advancement of the versions. By using the “make-your-own” repositories method, I will at least be able to certify a version even if it means I have to stay a version behind.

So… the moral of this story? There needs to be a way to have long term stable version points if you want to compete.

Will ERPNext Foundation ever get ISO certified? I doubt it, but if they give me the tools to do it myself (LTS version points) then “they” ( the foundation ) can still be a player in this field on the backs of folks like me.

BKM

Not_a_countant · January 9, 2018, 11:10pm

I don’t feel it is such a bad thing if they become a player on the backs of people like you. The community needs you. It’s a win win.

Whey exactly do you need for this to happen?

I don’t think i care so much about ISO, as it is an overhead and more of a marketing tool. That’s just an opinion. Don’t want to flame anyone

Julian_Robbins · January 10, 2018, 2:13am

I think the fact that there is a stable v9 branch from Frappe is a good thing and the community should work with them to improve this.

The trouble is that this v9 stable branch release has not been marketed very well apart from one forum mention and you cannot easily use it for a new installation as you state. The fact that you did not know about the branch when it could be so useful to you says a lot about this. It’s early days in some ways for the project for attaining the highest level of stability that you and many others require.

Libreoffice does something similar where the latest release is called Fresh and a more mature stable release for business users is one point release behind (usually a couple of months older). Security updates and fixes are available for both branches. Something like that would work really well here.

For me V9 has been the most stable release I’ve seen over the year or so I’ve been in the community. After some V10 testing I think there are some more noticeable bugs still to be shook out. I have a few I’ve submitted which have been very quickly fixed too

Don’t forget there are quite a few Devs that are paid and work for the Community as part of the Foundation and work closely with Frappe ie Acquinha, etc

Perhaps you should bring this up with @revant_one Profile - revant_one - ERPNext Forum who is the Foundation head ? I think he would be interested in this topic …

bkm · January 10, 2018, 4:31am

Therein lies the problem. There is not stable v9 branch.

If you follow the above link to the test results of the build on the v9.x.x branch, you will see that it fails to build properly and there has been no activity to correct it. Just a few post up from here I posted a screenshot of it clearly stating it failed (top of right column).

So at this point it is not really worth even attempting to use that branch to generate a functional system.

I agree. It is a win - win. The problem is not having a stable point from which to work on version 9.

Wrong question. It is not about when " I " need this to happen. It is when it makes sense for the foundation to make it happen for the good of the the product. Right now (at least here in the USA) the economy is on the upswing and businesses are feeling more comfortable investing in their business systems to support growth. ERPNExt ‘could’ be a path toward that. However, without a way for businesses like mine to easily install and work with stable releases, businesses like mine must turn to either other software that has such stability or try to make our own stable release points. To me, that would suggest that “now” is the time for the foundation to put this process in place and try to catch the wave of small and medium businesses here that are looking to invest in themselves with new software.

And you are right… ISO certification is not something I would expect the foundation to take on. That is supposed to left to people like me (at least at this stage of the project).

BKM

clarkej · January 10, 2018, 4:18pm

I agree the Foundation should find resources to fix v9 to run ‘green’.

edit: change from ‘insist’ to ‘find resources’

bkm the test run results are not entirely abysmal, for example this result:

<unittest.runner.TextTestResult run=693 errors=2 failures=2>

says of the 693 tests that ran, 2 did not run - due say for eg a test setup error? - while 2 failures means that while these 2 tests ran and completed, but that the expected ‘assert’ result did not match.

Another point is note and distinguish between a ‘build failed’ versus a ‘successful build’: With the latter a given test suite did indeed run, but that some individual tests had an error or failed result. Of course a ‘failed build’ means the tests did not run at all.

bkm · January 10, 2018, 5:28pm

While that may be true, I cannot in good faith use such a repository to generate an instance for my clients data to run as a production server. They are depending on me to provide only tested and functional software as their system base. If they were ever to take it upon themselves to look into the repository test results, I would have a great deal of explaining to do. That is not a good starting position for me to build a trusting relationship with my clients. Nor do I want to have to be the one to try to explain the failure results to them. Not matter what I would say, they would always have a nagging question about reliability in the back of their mind.

Also, I have yet to find a way to even make an installed instance from this branch. The few suggestions above ALL rely on an existing instance to be the starting point. From my past experience with updating ERPNext/ frappe / and bench, I would never be comfortable with the resulting system. None (as in never) of my past attempts to do an upgrade have ever worked right away and without error. So, unless there is a way to do a CLEAN install from a tested branch, I am not going to waste my time.

At this point I am trying to locate a contractor to generate for me a tested and working set of instructions for pushing my own repositories from a known working instance. I am not a developer and do not have the resources to train myself up enough to handle anything other than installing and configuring the systems. So, a set of instructions for either installing from a tested branch or for pushing my own repositories are my only options.

Since it appears the foundation is not making any effort to support v9.x.x branch, then my only real option is to find a way to create my own repositories.

Someone else asked why I don’t make my own fork of the system, I am not opposed to that, but I have no idea how to do it, and there is no comfort level with the current v9.x.x branch. Also, it comes back to not having any idea how to do a clean install from any other repository or branch in the first place. That brings me back to my search for a contractor to set this up for me.

Ultimately, I need to secure my own repository (so I know it would not be tampered with after testing) and have a custom install.py built to use the secured repo for generating clean installs. So my search for a contractor continues.

As I mentioned before, the lack of a way to do the clean install of version 9 forced me to place the most recent client into a commercial software solution instead of ERPNext. This means I am not as rushed as I was last week to get a solution. I have already given my hot client a system and they are busy learning how to use it now.

So I will continue to look into using an existing and tested instance to generate my own repositories and then am install script to use the new repos. This really seems like the only self-sufficient method I have heard of for supporting my clients properly.

Hopefully I can find a contracted solution in the next week or two. I really need something this month for my next client.

BKM

bkm · January 10, 2018, 5:45pm

Wow, my ERPNext ALERTS are not working as they should. I have been here on this thread and a few hours ago @nabinhait answered my original question about how to do a clean install of the v9.x.x branch on another thread. I just got the alert here several hours later.

So for those interested, please see the following post:

The relevant instructions are near the bottom of the thread. There is also another post further down explaining how to set the branch to the v9.x.x for use with install.py See them here:

All good news. Now I just need to see a green test result for that branch.

BKM

clarkej · March 8, 2018, 6:17pm

As a footnote to green tests BKM, test coverage matters too. That is the way forward