Workaround:

Before updating Joomla, edit libraries/cms/version/version.php and add these into the class:

	/** @var  string  Product name. */
	const PRODUCT = 'Joomla!';

	/** @var  string  Release version. */
	const RELEASE = '3.4';

	/** @var  string  Maintenance version. */
	const DEV_LEVEL = '8';

Just remember to update the version information and save the file. After that upgrade works from admin...

Do you want to send a pull request so we can review?

how can you reproduce that?

If you are on 3.4.x at this place the old code from 3.4 is executed => no problem.
If you updated to 3.6.x the new code is used and worked (as the constants exists)

Btw the code change (4c4d626) is and work there since 3.5.0 so the same problem needs to popup also on 3.4.8 -> 3.5.0 but it don't do?

I have just double checked that and can't reproduce it by updating from 3.4.8 -> 3.6.5 => No issues.

Can you please double check your introducions to reproduce the issue?

I had to step into another task, but I've not forgotten this one. What seems to happen to me is that the old version of JVersion gets used with the new version of the updater script.

I'm using phpbrew with default php.ini (except for small tweak in download size) with opcache.revalidate_freq=2, which may cause the issue.

I think the issue may be related to above setting, I do now remember that there was issue with revalidate_freq which caused a long discussion on how to fix it.

The issue happens to me every time on a clean Joomla install. I may have an idea how to fix it, though -- I will get back to you shortly on this.

If the 3rd Party Code is not broken this script should clear that kind of cache (if your setting not ignore this) https://github.com/joomla/joomla-cms/blob/staging/administrator/components/com_joomlaupdate/restore_finalisation.php

The only szenario i know that 3rd Party script don't trigger that file is when you come from 2.5 as a very old version gets expected.

@mahagr is there a PR coming?

I was again reallocated to another project and because of it I never had time to look into this one.

I did confirm, though, that the issue comes from opcache.revalidate_freq > 1, which means that some of the classes (like JVersion) were cached from the previous request and is affecting the update script.

There are a few ways that this could be worked around. One way would be to detect if JVersion comes from the old version, attempt to clear opcache and redirect to a page, which asks you to complete the installation with some explanation of what is going on.

@mbabker have done PRs about Cache, one is #13357

This issue has nothing to do with cache, but PHP using an old version of the class.

to high for me, read opcache and thought "Cache"...

There is no way to detect if the JVersion class comes from an old request or whatever without explicitly flushing all the caches and reloading the file first. Which kinda defeats the point of having a cache at that point.

As long as you're updating with the update component, its finalization step (the last thing it does before moving from restore.php back to the Joomla environment) tries to clear byte code cache.

Can someone try updating some older version (3.3 or below) with opcache.revalidate_freq=600?

This seems to be nothing, we can fix from Joomla's side. The problem needs to be documented together with a description on how to solve it through correct server settings.

Thanks for the update @nibra please dokument that behavior and link it back here. ?

Set to "open" on behalf of @nibra by The JTracker Application at issues.joomla.org/joomla-cms/13201

Should not be closed before the documentation is created / updated. Otherwise, it will go lost.

There for we have the doc label (that i have just added)? But you are the leader so you can decide. Thanks.

Set to "closed" on behalf of @nibra by The JTracker Application at issues.joomla.org/joomla-cms/13201

Added caveat to documentation, see https://docs.joomla.org/J3.x:Upgrading_from_Joomla_3.4.x_to_3.5

True, I didn't find a proper solution for this even after a few tries. It is nice to see it documented, though!

@nibra Can you fix the documentation, though.. The value needs to be 0 (turned off) instead of 1 second.

Fixed documentation.