So far I’ve found one single topic about a v13 change here, and while there’s a whole commit history I would imagine that new features have to be settling down at this point. I’m wavering on whether to start with v13 on a new project since go-live is a couple months out, or if I need to be conservative, only I simply don’t have a clue what’s new.
Also, would it be possible to update the downloadable virtual images with branch and build dates?
You can expect more news about ERPNext v13 this month, stay tuned!
There would not be major changes to any ERP project on the way. I don’t think the implementation should be given any time to cool off.
Moreover, the newly introduced features may add some uncertainty to the cutover so I would go with the last stable release as long as there is no obvious showstopper to choose the last version.
Out of an abundance of caution I have discovered that operating on a previous version when going live is always a good idea. Once settled, you can use a copy of your production instance to rehearse updating to the new version. We did this with a customer this year and had no problems whatsoever. we are still in pre-production but heavily developing several customizations.
You mean, first phase you implement version N-1 since version N is still not stable. Operating for one year (more or less) then you proceed for an upgrade right?
I think even recent versions can be very stable, but if you have development and auditing processes happening concurrently an n-1 strategy might be your ticket. Another option is to lag n-.2 or n-.5 versions behind.
Once you are comfortable backing up and restoring databases from server to server, the version thing is not too much of an issue, and we seem to flow “naturally” between N-.2 all the way up to n-1.
Doing n-3+ will have you missing great new features.
I did decide to just start with 12, the risk of an unfinished feature being ripped out or a big change landing and making the whole system fail is too high. It’ll be in development for a bit anyway; once the 13 beta/rc comes along I’ll see how badly I want any new features. I have a pretty high tolerance for pain, so I’ll probably try to keep a stable and next after that, and report or help out if anything comes up.
Particularly waiting for document management, or improving in quality.
For example, I would like to open word documents, as SOP, inside the ERPNext, with the user restrictions applied…
In ERPNext v13 and next releases, I expect better reports for Education Module such as those suggested Report Card Generation for each student Suggestion for assessment result in Erpnext schools module as well as in Suggestions/Fixes for Assessment Result Tool #8737.
January ended, when could we hear the news?
Is anyone in a hurry to see v13 ? I know am not. Still trying to stabilize v12. Many functionalities not working to spec yet. We should not just ignore this and jump to a new version.
Let’s focus on fixing the broken!
@olamide_shodunke One thing gets fixed and another gets broken. It’s pretty worrying that this happens all the time. The latest is workflow auto email alert. I raised the issue after v12.5.0 was released and so far no word on if and when it will be fixed. This is really critical for users that rely on workflow and i can’t figure out how to implement the Workflow Action within a custom email alert.
What’s the issue? None has reported any issue so far.
@nabinhait email alerts are no longer sent on workflow state change. I reported this issue in this thread and this change could be the culprit but as i am not a developer and don’t know much code this is just conjecture. But this issue only came up after v12.5.0 which included the workflow action PR.
I have spun several test servers both on a local machine and cloud VPS with no data and tested just to be sure the issue is not with my production instance and in all cases i could replicate the issue as workflow state change does not generate emails while other email alerts such as new user creation and password reset which are automatically generated work as expected.
I honestly cannot tell why no one else has reported the issue. But i am assuming someone who uses the standard email alert feature will notice soon enough and report same. I am reporting it because i rely on it heavily and as demonstrated in this thread i cannot set up my own custom email alert to function the same way without help from community.
I have accepted that some things might break going forward as the core changes and improves. A workaround is always to build your feature as a custom application, so you control 100% what the code does. If at any point the core code change breaks something, it is a simple matter to check the error and traceback the process.
I understand this might be tedious to some, but It is a small price to pay to have open source code with CI /CD. I prefer to suffer these consequences than having a licensed product change without me being able to adapt a priori, or worse yet, have the license “revoked” by the software supplier.
“With great power, comes great responsibility”
Yes that plus no license required - for better or worse 
I agree and I have chastised a few who have complained about missing features before because I believe that if you want extra features or functions, if you cannot get anyone to create the feature or function within the community then pay a developer to do it for you if you lack the competence. But when an existing core function breaks especially as a result of an update or a new feature, it saves time and more beneficial for everyone if the change that caused the function to break is studied rather than ask everyone to sort themselves out individually, that can be messy.
But when you say “It’s free so suck it up” as @clarkej’s sarcastic remark here suggests, it defeats the whole idea of putting in time to make the application better. The fact that it’s free does not mean it has to be useless to the end user. If it is useless to the end user then what is the point? If people find bugs and report them especially when they result from recent changes, that’s not being unappreciative, that’s helping the application become better. If you have to spend thousands of dollars to maintain a free application because it breaks everytime then the application is not free in the true sense, that’s paying to use the application by other means.
I appreciate the work of every developer that have contributed to making ERPNext what it is today, i really do. But it is unhealthy to promote the notion that because the application is free and opensource, don’t point out issues, put up or shut up. I am sure many would have seen this same bug but chose to be silent because they don’t want to be ridiculed for pointing it out. And it is not good publicity for an application that is growing to compete with some of the best applications in its category.
Preach !!
Would love to have branch accounting introduced in v.13. Instead of installing separate instances for each branch, it would be great to have all branches under one umbrella and then have a feature of consolidated accounts.
Uhm… not so fast please.
I am sure that was not the intent of @clarkej posting. He, like the rest of us understand that we do not and cannot exercise very much control over how an opensource project evolves unless we each contribute to making it better.
I am sure that @clarkej and others (myself included) have all contributed to the core project in some way and at some time. It is what we do if we believe in something enough to want to use it in our own businesses. Many of us have spent thousands of dollars on contributions to this project. Once those contributions are included in the core, we no longer personally have to support them. They become part of the overall project and are supported by the core developers.
How many other opensource projects do you know of that work that way?!?
Most force a sort of app store approach where you have to download other peoples work and add it to a project yourself. After that, if something breaks you are waiting for the party that created the add-on application to fix it! That to me is just as perilous as hoping a core team can always get it right. However, the core approach makes life easier on everyone at some point in the future. Right now they just happen to be having trouble managing the size of this extraordinary project.
So, just focus on reporting bugs in the GitHub Issues section and help if you are able.
I am sure @clarkej comment was just an acknowledgement of this process “for better or for worse.” 
BKM