I got some time to watch replay of Frappeverse 2026.
But after watching various presentation by Frappe employees I have become confused as to which feature is available in which version of Frappe and/or ERPNext.
There is talks of AI. Here I could only understand the generalized theory presented by @rmehta and then usage example presented by @buildwithhussain
In one there is talk of integrating Frappe UI/UX to Desk (pages) but in which version? It is possible to just update to the latest version of Frappe Framework and run ERPNext version 15 on it seamlessly? Will the new components get automatically updated in ERPNext version 15’s UI primitives? I am especially interested in List View table and child table.
There are many talks on new features already introduced or coming soon in ERPNext.
But on presenter categorically mentions which version of Frappe Framework/ERPNext these features are for.
At the previous Frappeverse 2025, Frappe Studio was touted as the next big thing coming to the Frappe world, but this year, it was missing (or did I miss it). Why? What is its current status or is it a stalled project now?
This year Raven seems to take the spotlight and rightfully so.
One extra question:
Frappe Builder (claims that it) is now powered by AI again here the details are very skeptic. I mean which AI/LLM is used and does it support BYOK or not? Does AI in Frappe Builder work when setup locally?
As per my discussion with Frappe Team during Frappeverse 2026, Version-15 will not receive any of the new features. Version-15 will only receive the bug fixing till EOL.
Version 16 may receive some of the new features but don’t expect everything. You may see all these changes in version 17.
A lot of the new features have already been shipped in v16 - the new banking module, improved global search etc.
The other UI updates on Desk like the new settings dialog, the updated sidebar, kanban views, new print format builder etc - we wanted to ship these in v16, but since we’ve changed the CSS classes and selectors, we know a lot of custom apps would break. Hence we’re going to ship these in v17 instead.
In fact we’ve just laid the groundwork for what’s to come - these UI improvements will help us to build new user interfaces for existing modules much faster. These will also be included in v17 - for instance, we’re working on a completely revamped Projects module, much richer reports and forms, and a much easier way to onboard new companies on ERPNext.
We’ve also started work on a new Supplier and Customer portal - and this is being built using Frappe Studio.
I’m probably missing a few more things that we plan to ship in the next 3 months alone. Oh and I’m only talking about the UI/UX of ERPNext. We’re also working on huge backend revamps related to the stock ledger to make it much more reliable.
We’ve just started work on it, and taking a design first approach. This is new for ERPNext where we usually used to make the feature and then think about the design.
rtCamp’s project management system is quite good for service based businesses for project tracking. Do give it a try though!
Do I take it that they are not back ported to version 16 yet? Is there any time frame within which these features will appear in version 16?
Kudos to @rucha_mahabal for putting together Studio and bringing it to usable level. And thanks for this information. This piece of info is vital to me and builds my confidence in Studio.
Is Studio creating Desk pages or it is something else?
Are there any plans to also release breaking changes documentation so that developers can study it and make necessary modifications to get their apps working in version 17.
While I understand there are many products shipped from Frappe the company, that were developed for their own use and kindly shared via open-source licenses, their flagship product ERPNext and Frappe Cloud absolutely NEED a long-term release option.
I’m not aware of any enterprise willing to adopt a system with a 2-3yr EOL cycle for their ever so important ERP System.
With drastic architectural changes between versions, it’s likely the development time spent building custom apps and integrations with ERPNext will require significant effort to make them fully compatible with the next version.
This is unacceptable in Enterprise.
These drastic changes will push companies that have adopted ERPNext to stay on older, unsupported versions, which is not great for longevity or customer satisfaction (or security, for that matter).
PLEASE, PLEASE, consider an LTS model!
Just search the forum for “reverted to version 15” because a feature was removed that was heavily relied upon by the user.
From what I can see, ERPNext is at risk of “death by a thousand papercuts”.
How many users were relieved to finally get a stable version, only to find it’s nearly end-of-life, then disappointed that the newer version is full of bugs, has unusable navigation, dropped features, etc.?
v15 continues to receive support and security updates from the Frappe team. v15 was released Oct 2023.
The v16 release could have been done better though, especially the navigation issues which have been talked about quite a lot - both here on the forum and internally at Frappe. v17 aims to fix this navigation issue - do give it a try and let us know. It’s already available in the develop branch.
I do agree about having an LTS version though. You’ll see that in v17 the major breaking changes are for developers who have used internal functions (not public APIs that continue to function the same way), or who have manipulated the DOM directly instead of using the standard client scripts we have. Most of the breaking changes are in fact to address security issues which I think you would agree is kinda unavoidable. We’ve been very careful about not breaking anything else. AFAIK, no features have been removed, only added. Most of the features we’re adding that change existing behavior are gated behind feature flags. You could consider v17 a more polished v16. Migrations shouldn’t be a problem.
While we need stability, at the same time though, we do need to continue moving forward and building better things. For instance, we’ve seen quite a lot of issues related to the stock ledger and we have taken the decision to rearchitect it because that’s the best solution at hand.
Hopefully you’ll see that v17 would add a lot of value to users and I’m pretty confident that it will be a better release. If not, please complain here - we’re always listening.
This is the most recent example of a feature that was removed.
Breaking changes do happen, even when using the API. When Frappe takes two separate functions and combines them into one, with a different name and/or additiona/less arguements, but removes the two individual functions, I consider that a breaking change.
Perhaps you are correct, and we are using the system incorrectly. Considering this change; we were using the whitelisted function get_customer_primary_contact in our custom app. Is this a bad idea? Should we be duplicating all of the useful code and putting it in our own app? What would be the best/most efficient way to use that function, without being impacted by the breaking change?
I’ll have a look. Was not aware of the change in the budget feature.
I think using whitelisted functions is the right approach for custom app builders, so you’re right. Internal functions can change. Whitelisted methods can be removed in major version updates though - each whitelisted endpoint is a security dependency.
We’ll be more careful on how we approach changing these going forward. I know a lot of the security patches we have done affect whitelisted functions but that’s an acceptable breaking change IMO.
any planned release date for v17? I know it’s too early, but when v16 was launched, I remember one of frappe team mentioned an expected 2.5 years before v17 is released. I am eager to know if this has changed? @nikkothari22
@ahassoun If Frappe supports max 2 versions at a time then v17 should be theoretically released at end of 2027 which is when v15 reaches EOL
@volkswagner is right - “IF” you want to go for Enterprise customers (@francis1 keeps on complaining about that) then they would expect at least 5 years LTS. In fact even a SME will not want to rewrite code every 3 years, its probably more expensive (proportionally) for them than an enterprise customers who have large IT teams/budgets
I also request stability to be a priority as you scale to your stated goal of 1m users.
We are focused on stability. Huge refactors, an update to the entire test suite and the stock ledger rewrite currently underway are all examples of that. However, at the same time, we do need to improve the product. Odoo has a release every year btw.
With the pace of development these days, I think the community should also be open to the possibility that migration of custom apps would not take that much time. In v17 for instance, we have minimal breaking changes to standard APIs/client scripts.
The Project budgeting “feature removal” that was mentioned earlier in this thread was also made to accommodate a new feature - the ability to cancel/amend budgets for only a few accounts instead of all of them. Budgets can still be made for multiple accounts - just the flow is different.
Anyway, point being, you’ll continue to see faster updates to the product, and we will try to keep breaking changes to a minimum. We’ll also publish detailed migration guides between versions so that it’s easier to migrate.
if you look at odoo and SAP they do major upgrades yearly and they bring a lot of features the rate at which these ERP softwares evolve is at another level especially odoo l used to hate the upgrades but you may just need a week to write custom app to fix patches for bugs that comes with the upgrades but nothing like big outage or big bugs but here in frappe we cannot do that because we may not have enough budget
I strongly advocate for introducing a Long-Term Support (LTS) release model for the Frappe Framework. When deploying ERPNext for large enterprises, the current rapid release cycle often conflicts with the practical realities of enterprise-scale implementations and maintenance.
Here are the primary reasons an LTS track is critical for enterprise adoption:
Misaligned Implementation Timelines: A full-cycle enterprise implementation—from project kick-off to go-live—typically takes 8 to 12 months and often involves custom development to bridge functional gaps. By the time a project goes live, Frappe frequently releases a new major version containing breaking changes, immediately placing a brand-new deployment on an outdated track.
High Upgrade Friction and Cost: Enterprises do not adopt new software versions immediately; they prioritize stability. Upgrading an enterprise environment is not a simple automated process. It requires 4 to 6 months of rigorous staging and testing, plus an additional 2 months to retrain users, adapt UI changes, and rewrite Standard Operating Procedures (SOPs). Most organizations are unwilling to absorb these substantial upgrade costs more than once every 4 to 5 years.
Support Constraints on Critical Bugs: Enterprises generally value system stability over new features, but they rely heavily on bug fixes. Recently, an enterprise client on version 14 encountered a clear code-level bug in the Trial Balance Report. Upon raising a ticket, we were informed that version 14 is no longer supported and the client must upgrade to receive a fix. It is unfeasible for a business to wait through a 6-month upgrade cycle simply to resolve a critical reporting error in their current software.
The Proposed Solution Much like Ubuntu offers LTS releases for server environments alongside fast-paced releases for standard users, Frappe would benefit immensely from a dual-track approach. We are not asking for new features to be backported to older versions; we are simply requesting a commitment to extended bug resolution and security support for designated LTS branches.
Providing this long-term stability will build trust and significantly strengthen Frappe’s position as a viable, dependable solution for large-scale enterprise deployments.
Kudos to 