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.
1 Like
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!
1 Like
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
1 Like
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:
- Allow the user to drag-and-drop to re-position the boxes, everywhere. Sectional contraints can be applied.
- Allow users / the admin to hide some of the modules and menu items [by default]. Admins should be able to reduce features to only what is needed for a user / user group, giving ERPNext a clean and easy feel.
- Allow users to add a background image. Some people here had beautiful desk backgrounds, they’ll feel way more at home.
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.
3 Likes
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.
1 Like
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
It was about six weeks ago last time I tried it, but I believe it was just the entire frappe-bench directory. There were a few extra steps, like relinking nginx.conf, but all pretty straightforward as I recall.
So did you have to install python, nginx and mariadb before you unzipped the tarball or were you restoring the tarball to a server that had already once been an erpnext server?
BKM
It was a clean server, and then I installed frappe’s dependencies like normal. I can’t recall my steps exactly, but I suspect you could just follow the standard manual installation instructions and then just stop at the bench new-site command. I’m happy to discuss more, but it’s probably worth doing it in a new thread. Feel free pull me in if you start one.
1 Like
ERPNext is not a desktop application. It is an enterprise ERP system, which has many moving parts which work together.
From what I gather, you are installing ERPNext on behalf of your client. It would then be expected of you to manage the change.
A good change control process will document
=> pre-conditions and pre-requisites
=> the upgrade process
=> backup and recovery process
=> back out process
You cannot expect to cut and paste commands and hope it works. Often for production software, a beta system is required. You would be expected for major changes at least to perform the upgrade on a beta system. We are a small manufacturer and have both a beta system and production system. Because we understand the value of constant updates and the nature of the ERPNext system releases, we see it fit to manage upgrades in this way.
3 Likes