A general comment on versions, design and architecture changes

rmehta · February 16, 2019, 4:55am

Community,

Seeing the reactions from the community over the last few weeks on a few major proposed design changes, it is clear that there is a significant section of the community that does not want these changes.

Those who have been around longer, every few months, there have been major design changes like:

Introduction of apps and hooks
Moving to WSGI (from CGI)
Moving to Bootstrap UI
Rewriting the entire object-relational-mapping so that is becomes much cleaner and object oriented.
Rewriting of the desk UI from functional to object oriented.

Having a smaller community meant that there was not much resistance to such changes. At this point however, we realize that lots of companies have significant investments on the platform that they may not want to upgrade for the next few years.

The changes do still have to happen, we are a community of maybe 5000 users, but we need to think of the 500,000 users that are still to use ERPNext and from that perspective, we need keep improving the product rapidly.

To keep both the audiences happy, there is only one alternative. Users should be able to choose when to upgrade. As maintainers, I am proposing that we will support every version for a period of 4 years from its date of release. Support means only pushing / accepting bug-fixes and security-fixes. New features will always go in the latest version.

So in this way, companies that are happy with the old desk, old permissions or any of the new features that are being proposed, they can continue to remain on v10 / v11 for a longer period of time.

Note: We are also planning to maintain legacy versions on ERPNext.com cloud too. New signups will always go to the latest though.

vrms · February 16, 2019, 7:57am

that means the “LTS support” (pushing / accepting bug-fixes and security-fixes) would start from v10, right? So, practically v10 ( (git branch 10.x.x) would be bug/security fixed till Dec 24, 2021 (4 years after Release of v10.0.0)?

dufani1 · February 16, 2019, 8:55am

This is the best decision ever happen for ERPNext. I am sure this ERP will be the best one in next 3 years.

nmami · February 16, 2019, 9:07am

I support this approach…

wale · February 16, 2019, 9:50am

@rmehta ,

This is no mean feat! Thank you for always listening to the community and finding ways to carry everyone along especially as this project grows. You have my respect and admiration… and that goes for the entire team @frappe

Thank you all so much!!!

Witton · February 16, 2019, 10:12am

@rmehta This is a good move. Eventually when the system growing bigger, we need a way to control the system life cycle effectively. I can see this is similar to how SAP did.

Thanks.

vrms · February 16, 2019, 2:39pm

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.

clarkej · February 16, 2019, 4:39pm

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

brian_pond · February 16, 2019, 6:41pm

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

bkm · February 16, 2019, 11:25pm

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

brian_pond · February 17, 2019, 2:50am

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:

Entirely standalone on a VPS/machine that you own and control.
Hosted on someone else’s VPS, where you have less control.
Leveraging Docker, Bitnami, etc. (I’m really liking Docker this year, and deploying it everywhere).
Installed with install.py (which makes some decisions for you)
Installed manually.
Which version/branch from GitHub?
Dozens of possible operating system distributions.
Hundreds of possible combinations of prerequisites (Python,Node,Redis,MariaDB,Nginx)

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.

vrms · February 17, 2019, 9:31am

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)

bkm · February 17, 2019, 4:42pm

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

rmehta · February 18, 2019, 3:57am

All great ideas, all it now needs is someone to take charge and deliver

peterg · February 18, 2019, 2:59pm

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.

peterg · February 18, 2019, 2:59pm

Can you say more about what kind of community support you’re looking for on this, and more specifically how the relationship would work?

rmehta · February 18, 2019, 4:10pm

This has been thrown around multiple times, will add it again: Contribution Guidelines · frappe/erpnext Wiki · GitHub

peterg · February 18, 2019, 4:26pm

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.

bkm · February 18, 2019, 7:01pm

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

brian_pond · February 18, 2019, 7:47pm

^ 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:

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.