Administrator/components/com_joomlaupdate/src/Model/UpdateModel.php creates a new Update object in function checkCompatibility, line 1629 and below. It tries to set properties that do not exist in Update object.
This fix creates the missing properties.
Note : $jversion.full has been renamed $jversionfull.

I still cannot replicate the reported error. Maybe I am missing a step. Can you please make a screen recording showing everything you did to create the error. I use licecap for this.

Clean Joomla 5.0.3 install + any non core extension (I installed latest Akeeba Backup), PHP 8.2 or higher

Does the issue also happen with error reporting = none?
If no, then we have a readable workaround and we just should recommend that in the release announcement.

And does it also happen on 4.4? If yes, the PR should be made for the 4.4-dev branch, and that will later be merged up into 5.1-dev by maintainers. If no, the PR should be made for the 5.1-dev branch as there will not be any new 5.0.x release.

finaly I can replicate it. I was performing the update using the upload and update function and that produces no errors

I just tried a Joomla 4.4.3 environment and this issue does not occur.
Joomla 5 update class uses LegacyPropertyManagementTrait which causes notices display.

LegacyPropertyManagementTrait was introduced by @laoneo #40999 for 5.0.0

Oups, I blow it up while trying to rebase it to Joomla 5.1

@conseilgouz Have you just tried to rebase your branch? If so, it seems there went something Wrong. You should change the base branch on GitHub by using the "Edit" button right beside the PR title. Let me know if I shall do that for you.

@richard67 : well, after trying rebase from my PC, 1120 updated files ???? your help is more than welcomed.

@richard67 : well, after trying rebase from my PC, 1120 updated files ???? your help is more than welcomed.

@conseilgouz As said, it needs to change the base branch on GitHub. I will do that now.

what about the 1120 updated files ?

what about the 1120 updated files ?

@conseilgouz Check again. Now there are only 4 remaining. But there are still some unrelated changes in files plugins/content/vote/src/Extension/Vote.php and plugins/content/vote/src/Extension/Vote.php shown. Could you check and revert?

it still contains my other PR#42933

it still contains my other PR#42933

@conseilgouz Yes, because you have rebased to YOUR 5.1-dev branch, and you have made the other PR not on a separate branch but on the 5.1-dev branch. You should have rebased this PR to the UPSTREAM 5.1-dev.

@conseilgouz P.S.: Just revert these changes here and this PR here is ok.

are you sure that it is ok to rename jversion.full to jversionfull ?

are you sure that it is ok to rename jversion.full to jversionfull ?

I checked in all the sources and it's only used in Update class and in JoomlaUpdate Model.

but why rename it?

I did not find a way to define a variable with this kind of name (with a dot).

just seems wrong that to fix the bug you need to change the name of something that has been in use for a very long time.

@laoneo as you made the change to LegacyPropertyManagementTrait in #40999 for 5.0.0 does this look correct to you.

It smells of being a bandaid to fix a bigger issue

jversion.full is just a variable.

It's only used in Update class with a preg_match (line 364) : preg_match('/^' . $this->currentUpdate->targetplatform->version . '/', $this->get('jversion.full', JVERSION))

In PHP 8.2, we have to define it before using it in an object, otherwise it sends a deprecated notice but it creates it anyway.
In PHP 9, this will cause an error.

I had to change variable name as I did not find a way of declaring a variable with a dot in its name.

FYI, in Joomla 3.10, jversion.full was already there and there was also jversion.dev_level (never initialized, so containing Version::PATCH_VERSION). Both variables were used in Update class the same way they were in later Joomla versions.

Thanks @conseilgouz for the finding. We have to discuss how we handle this issue best. It need to be fixed asap, but either it will trigger a new 5.0.x or we will move it to 5.1.1. Sadly 5.1.0 is the wrong version for it, but we get it managed :)

Thanks for the finding and the PR.

Edit: just saw that @brianteeman mentioned it before, yes it's #40999 (tbh it's when the trait was implemented in 4.3 and was not replacing the full functionality). The dependency of stdClass was removed by this PR, so we have to think how to solve it.

@conseilgouz can you rename the variable jversionfull to $targetVersion? Like that it is more meaningful. Also remove the set and get calls and make a proper setter function like `setTargetVersion for it with the? Thanks...

@laoneo : ok for targetVersion. In progress...
What about other variables that have been added "the hard way" : downloadurl, tag, stability... ?
It's not the purpose of this PR, but could be cleaner

@laoneo : ok for targetVersion. In progress... What about other variables that have been added "the hard way" : downloadurl, tag, stability... ? It's not the purpose of this PR, but could be cleaner

You mean to make getter and setter functions for them?

@laoneo : ok for targetVersion. In progress... What about other variables that have been added "the hard way" : downloadurl, tag, stability... ? It's not the purpose of this PR, but could be cleaner

You mean to make getter and setter functions for them?

Well, I was thinking about this, but it's tricky to find the "getters" and the variables are set in _endElement thru a nice foreach (get_object_vars($this->latest) as $key => $val) {
$this->$key = $val;
}
So the setters are also not that easy to create.

Everything seems to be ok (thank you @richard67, @laoneo for the time you spent ), but, it applies to Joomla 5.1 when initial issue was about "J5.0.3 update to J5.1.0 does not work".
Did it worth the time we spent ?

@conseilgouz Well we can’t fix it for 5.0.3 with a CMS update, and we have a workaround for this, switching off error reporting, but we need the fix also for later updates from 5.1.0 to e.g. 5.1.1 in future, so it is ok for 5.1.

@conseilgouz You‘ve deleted your fork of the joomla repository, so this PR was closed. Was this a mistake or by purpose?

Hi Richard,
I had 2 other PR's which said I could delete my fork and I forgot about this one.
I thought it was already closed.
need a "refork" ?

need a "refork" ?

@conseilgouz I think so. The PR was not closed by us, and it was approved by @laoneo , so it would have just needed 2 human tests. If you still want to provide a PR, I think you have to fork again and redo the PR.

New PR is #43410 . @laoneo Could you approve that one, too? It’s the same as this one here which had been closed by mistake.