For now the idea was to first label issues by Module getting them into some sort of order as a first step.
another outcome from the aforementioned meeting was to design a development roadmap (which I think is based on what has been discussed in this topic here). This may be prioritizing the open issues then as well I think. We’ll keep you up to speed with developments in that regards as well.
…
If anyone is interested in more directly influencing the direction things are going, feel free to join the foundation (for now individual membership is USD 200/year).
There is an online meeting doing down each Thursday. From my experience so far … the one who speaks out in those meetings has a good chance of steering the project.
1. Close a lot of open issues - the number just keeps increasing.
2. Instead of focusing on new features major features, the current features really need to be fixed.
3. I am still using V6 because v7 changed too many things that would break in my setup, and v8 won’t be any better. I really do not want to upgrade and change my configuration only to find the software full of new issues.
Hi,
I understand ERPNet is targeted for MSME’s. I believe the following will attract a lot of micro-small industries to ERPNext.
Why not start with a flexible HR Module - something every organisation needs.
Simple App creator - This should help implementors/ users to create simple forms to enter data.
Simple report generator - select any data filter and formulas to compute results on a dashboard.
App and report generators can drastically reduce the time and costs involved in implementation for any module and further enhance the flexibility of ERPNext.
One of the Most Important feature ( i guess will be required by all of us ) is the ability for the same customer to be a supplier without making 2 accounts for the same company, as i might be doing some contracting job for company X but for some reason i took some materials from company X in terms of a Debit note, so i could add these materials as bought from company X as a supplier and still my customer at the same time.
that’s great. The easiest way to get started (assuming you are new in this) would be to dive into the open issues and see whether you can fix anything.
I just want to be able to run the “bench update” command and have it actually update the system to the latest revision. Currently, it generates tons of errors about things being updated that require commit or stash. Then you run into another large list of permission errors.
As an implementer (not a programmer or developer) I cannot understand why I have all of these errors to suffer through to simply update my system. I did not do anything but install the system, import items and customers, then add and configure users. Yet I get all of these errors. I made no program changes, so the errors must have been caused by the install.py program when it was first installed.
So, yes, I have a simple wish that when a release is push out, it should not generate any errors when one tries to update it to the next revision.
Anything less than this is a huge red flag to businesses that want to adopt this as their ERP solution.If the business could afford a developer staff to try to decipher the errors and fix the issues, then they probably could afford a commercial ERP system instead.
At this point I think it is time for version stability. Rather than trying to push out new versions every 2 months, how about making sure a live productions system can easily upgrade from the last version to the new one you release without such headaches.
In order for this project to become the next real viral or killer app, it must become upgrade friendly. Otherwise, people will use it only once to get their feet wet with ERP and then move on to a system that is much easier to maintain. You will have lost them to any future features or improvements simply because they do not want the endless headache of trying to maintain ERPNext with no documented success path to upgrade.
As of right now, if you are sure that no modification has been done to the files you can use “bench update --reset” in order to reverse al file changes. Keep in mind that if you use the Delevoper mode you might be overwriting some files in the file system.
odoo upgrades didnt always work, but I dont recall seeing upgrades over a year of use that were broken as fields werent assigned etc.
I think also I’ve seen other times that a git stash or reset is reqd when I didnt see this once with Odoo. Not that they are very good or anything, but agree with the poster that the upgrades break a little too often for comfort (even if a fix is available often soon after)
Regarding comments by @bkm and @Julian_Robbins: Perhaps ERPNext could adopt an LTS strategy like Canonical tries to with Ubuntu. A two-ish year cycle. Opting out means that there are features you’ll lose out on and some critical things like security fixes and some bug fixes. But it would make for a more stable environment for customization and likely, a more painful user experience in the LTS upgrade change. It’s a trade off. Personally, I’m a fan of shorter cycles.
Shorter cycles are fine, but only if a true effort is placed into creating the upgrade path for each release that does not result in endless stash, commit, or permissions issues. I am handling these issues in other posts to try to get my production implementation to level up.
So much effort is placed into making a good product, but not enough time is being spent on bringing your user base along with you as you progress the product forward. I just believe that is a mistake in the long run. It alienates system implementation specialists and regular users and limits your loyal following to only the developers and programmers that can figure out on their own where the errors are and how to get around them.
To build a true loyal following, the ability for EVERYONE to level up and follow the product is essential. It does not however mean that you have to stifle progress. It just means adding the the task of testing the upgrade path to the normal workflow of creating a new version. It would be no different than adding continued support for a new module. The work load is about the same.