User tests: Successful: Unsuccessful:
Pull Request for Issue # .
This pull request (PR) changes the Joomla Update component and the updater so that the right update channel is used when using TUF, which is the default for the core.
It fixes the issue that currently when being on 5.1.0 Beta 1, and update to Beta 2 is found if you have selected a suitable minimum stability (Beta or lower), regardless if you have selected the "Default" or the "Joomla Next" channel.
The #__update_sites
table is extended by a new column where the desired update channel is saved. This allows the Joomla Update component to detect changes on that and to purge old updates from the #__updates
table when that value has changed, and the updater is able to check that value.
Theoretically the channel and so this PR would not be necessary if we would make sure by the targetplatform
that one can update only to 5.1 when they are at the latest 4.4 version (which currently is 4.4.3 and will be 4.4.4 soon).
But that would mean that we would have to update the targetplatform for every 5.1.x update with every new 4.4.y release, and in future we would have to do that for 6.x releases with every new 5.y.z release, where y is the last minor for J5.
And as you can see here https://update.joomla.org/cms/targets.json , we would not require that if 4.4 would already use the TUF-based update site. The targetplatform
versions of the 5.1.0 Beta 1 and 2 targets are "(5\\.[0-4])|^(4\\.4)"
, so we currently allow updating to 5.1 also from versions 4.4.0 to 4.4.2. And so I assume it will be the same in future with 5.x to 6.
And with the XML based update site which is currently used by 4.4. it is the same, see https://update.joomla.org/core/list.xml and https://update.joomla.org/core/j4/default.xml , the targetplatform of both the list and the details XML only requires 4.4, not 4.4.3.
So if we keep it like that for now and in future, this PR here makes sense in my opinion.
If we change that and require always the latest 4.4, then this PR here is obsolete, and we should delete the "4.4.4-2024-03-28.sql" update SQL scripts and add them to the list of deleted files in script.php, but as said, it would mean to change the targetplatform
versions all the time.
@bembelimen @LadySolveig @Razzo1987 I think it needs a decision here.
libraries/src/Version.php
and change public const EXTRA_VERSION = 'beta3-dev';
to public const EXTRA_VERSION = 'beta1';
.The Joomla Update component doesn't care whether you select "Default" or "Joomla Next" as update channel.
The Joomla Update component uses the right TUF update channel for the "Default" or "Joomla Next" channels.
Using the "Custom URL" channel works as well as before.
The Joomla Update notification icon in the Home Dashboard works as well as before.
Updating works as well as before.
Please select:
No documentation changes for docs.joomla.org needed
No documentation changes for manual.joomla.org needed
Status | New | ⇒ | Pending |
Category | ⇒ | SQL Administration com_admin Postgresql com_joomlaupdate Installation Libraries |
Title |
|
Labels |
Added:
bug
PR-5.1-dev
|
so we currently allow updating to 5.1 also from versions 4.4.0 to 4.4.2.
This is true. I wonder if it is not correct (and also easier for developers) to force a user to upgrade to the latest version of a branch before moving on to the next one.
@Razzo1987 As I have explained in the description this would require to update the targetplatform on the TUF repository every time a new 4.4 release is made.
I have tested this item ✅ successfully on 39262d8
I was able to test this successfully.
(Thanks to @richard67 for clear/precise testing instructions :) )
it would be more consistent with current behaviour (for the last x years) that you have to update to the last release in a series before you can upgrade to the current release in the higher series. Sure the update to the targetplatform on the TUF repo can be automated?
Sure the update to the targetplatform on the TUF repo can be automated?
@brianteeman Would be good. But I don’t know if that is the plan or not because I am not involved in any TUF related team or in such basic discussions. I only see it is not done that way right now.
ah - dont say we're back to having silos
ah - dont say we're back to having silos
@brianteeman No, I don’t say that. It’s just that I don’t really know if there are any plans or not.
P.S.: I am absolutely okay with it if this PR gets closed and the issue is solved in the other way. But it should be solved before 5.1.0 stable and not after it. The Joomla Update is too important for having half baked stuff in my opinion.
Maybe the description was a little bit misleading, so I've corrected it. 4.4 does not use the TUF-based repo, it uses the old XML-based repo. But there the same applies what I had written for the TUF-based repo: The targetplatform for the 5.0.3 update does not require 4.4.3, it only requires 4.4. See https://update.joomla.org/core/list.xml and https://update.joomla.org/core/j4/default.xml .
I have tested this item ✅ successfully on 39262d8
Status | Pending | ⇒ | Ready to Commit |
Setting RTC as it has 2 successful tests.
But also setting the RMDQ (release managers decision queue) label because release managers and other maintainers may decide to solve the issue differently.
@LadySolveig @Razzo1987 @bembelimen I hope you are ok with that, otherswise remove RTC or ping me to do that. Meanwhile I think the issue is not so urgent. It will become urgent when the first updates to 6.0 will be offered. Take my PR as one suggestion how to fix it, and I am happy if someone can find a better way.
Maybe the description was a little bit misleading, so I've corrected it. 4.4 does not use the TUF-based repo, it uses the old XML-based repo. But there the same applies what I had written for the TUF-based repo: The targetplatform for the 5.0.3 update does not require 4.4.3, it only requires 4.4. See https://update.joomla.org/core/list.xml and https://update.joomla.org/core/j4/default.xml .
That is not correct. Updates from J4 to 5 are done via this update server which respects the targetplatform via list_sts.xml https://update.joomla.org/core/sts/list_sts.xml
To me the correct solution would be to implement this stuff on the update server / TUF side to be more flexible and not hardcode different solutions which need to be tested etc.
Status | Ready to Commit | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2024-04-01 19:12:23 |
Closed_By | ⇒ | richard67 | |
Labels |
Added:
RTC
RMDQ
|
This is true.
I wonder if it is not correct (and also easier for developers) to force a user to upgrade to the latest version of a branch before moving on to the next one.