Release v12.2.3 not fetched when update bench

There are actually 2 problems being discussed:

  1. Can’t get from 12.2.2 to 12.2.3
  2. Some installation methods (install.py?) do not provide appropriate .git settings for updates.

@Akram_Mutaher solved the latter. The former is still in question.

So do we have the solution yet? or what is the verdict?

Hi, Do we have the solution for the issue yet, as I am experiencing the same issue as well.

We seem to be waiting for the creator of release 12.2.3 to jump in and tell us how to get it.

Well, nabin released 12.2.3 a week ago https://github.com/frappe/erpnext/releases

So when 12.2.4 is released, if the update stays stuck this pesky trend will need to be escalated…

I guess 12.2.4 is essential.

I attempted to install the newer version on another server, despite all efforts it is failing.

if i want to install

ERPNext: v12.1.6 (version-12)
Frappe Framework: v12.0.16 (version-12)

what should i do?

I think you must go to apps/erpnext and execute git checkout v12.1.6 then apps/frappe git checkout v12.0.16

I tried to install 12.2.3 from Bitnami,

even though it says 12.2.3 but after installation it is still on 12.2.2 so there is no 12.2.3

I wonder if this issue is simply a matter of semantics.

During an implementation for a customer, we updated after the release of version 12.2.1, but noticed that the version was still 12.2.0.

If you track the three files that where changed in that release, by clicking on the link shown below, you will find that never was the __init__.py file updated. That file is responsible for saving the variable tracking the version. Said variable is the one shown when you run:

bench version

AND to the end user when clicking Help > About and found under Installed Apps

I did some investigating and noticed that the file:
frappe-bench/apps/erpnext/erpnext/__init__.py

Shows only two modifications since the 12.2.0 release:

For the 12.2.0 release, the __init__.py file shows the following changes to line 8

For the 12.2.2 release, these are the changes shown to the file:

As of the moment of this posting, this was the last change to the file. You can track the change history to that file here

Could it be that despite the fact that a release was drafted as v12.2.3, we are reading to much into it and in reality the only problem is that the __init__.py file has not been updated? After all, it is evident that only 2 files were changed for the v12.2.3 One of them is not the __init__.py which remains at v12.2.2 as of the original time of this post!

2019-12-19 16:39:45 UTC

May I suggest not to get overanxious about the precise release version from Github and the version shown in the installed program?

Github is working fine, and you are getting the latest, even though the program shows it is -0.0.1 versions below. Make sure you actually check the changes in each file per each release, so you know for sure what features you have.

Let me remind how this discussion was started.

The actual problem was “Landed Cost Voucher” please follow this link for more information.

Landed cost voucher has been a big problem. After posting a voucher you cannot add another voucher.

You cannot even cancel a posted voucher. In order to test it, I installed the ERPNext from Bitnami as the installation was failing from github.

It is still the same even we installed it from Bitnami.

Following is the thread where we have the problem:

1 Like

true, maybe I am unaware of something previous to this topic.

From my perspective, the first post talks only, and precisely about the version changes issue.

To avoid confusion please let’s agree there are two problems, your LCV one and this update one thanks…

1 Like

It’s totally OCD on my part, so I don’t want to make a fuss about it, and I certainly don’t expect anyone to jump into action either, but …

I have ErpNext in a VM and I’m constantly reverting snapshots and retesting configuration changes.

<rant> This means I am either manually removing that hey-cool-look-guys-therz-a-dope-new-update-waitin-for-ya modal pop up or adjusting my Cypress scripts to deal with it. When things ain’t going well it’s just another ‘awferfcksake’ moment in a long day. </rant>

So …
My issues. Not yours.

We have new release it’s solved our issue :grinning:

It is so disappointing how and why the code quality is declining so fast!
The code tests are so overrated when it comes to business rule driven, labor intensive software.

Let us not ruin this strong project and discuss how to increase code quality in releases!

1 Like

Please explain what you mean by overrated!?

The “assert” testing holds and directs the developer for creating an output which satisfies the testing condition. It is only and just that!
The Exchange Rate doctype had everything in place but did not represent the business rule and did past the code tests. We just cannot rely on this!
There should be BPX: Business Process eXperts evaluating these changes and walking through the kernel code for critical changes. An ignorant developer changed the currency format just because he knew python and javascript but did not grasp anything about I8n and ERP development. This still continues. Nobody even bothered.
You cannot pitch a software like this to a customer.

1 Like

Best to start a new thread, I should have suggested that @Tufan_Kaynak2

You have lost me after assert testing!