As far as i know you can't update from 3.* to 4.*. Best to install https://developer.joomla.org/nightly-builds.html

This isn’t a core issue, I’m going to say you have a component calling JSubMenuHelper and when the site gets to an upgrade point it dies because JSubMenuHelper cannot be found anymore.

I can confirm what @franz-wohlkoenig said: There is no valid update path from 3.9 to 4.0.

The database schema update SQL scripts will fail with errors because several reasons, e.g. the privacy extensions which have been added with 3.9 are not integrated into 4.0 yet, and new extensions in 4.0 use extension ID numbers which are already used for the privacy extensions and others in 3.9.

So even if you get the update for the files working, then you end up with database errors which can't be fixed by the database schema fixer.

I've once tried to fix all that on my local development environment for making a pull request later, but I saw no way at the end because too much to be done first, e.g. integrating the new 3.9 stuff (e.g. privacy stuff) into 4.0, which is beyond my knowledge and capabilities, and so I gave it up.

I don't even know if it is planned to have a valid update path from future 3.10 (with 4.0 compatibility layer) and 4.0, or if upgrading 3.10 to 4.0 would be done with a kind of migration.

So finally I suggest to close this issue here.

J3.10 will be the upgrade path I do believe, this release is to be a stepping stone between the two.
On 22 Dec 2018, 11:41 +0000, Richard Fath notifications@github.com, wrote:

I can confirm what @franz-wohlkoenig said: There is no valid update path from 3.9 to 4.0.
The database schema update SQL scripts will fail with errors because several reasons, e.g. the privacy extensions which have been added with 3.9 are not integrated into 4.0 yet, and new extensions in 4.0 use extension ID numbers which are already used for the privacy extensions and others in 3.9.
So even if you get the update for the files working, then you end up with database errors which can't be fixed by the database schema fixer.
I've once tried to fix all that on my local development environment for making a pull request later, but I saw no way at the end because too much to be done first, e.g. integrating the new 3.9 stuff (e.g. privacy stuff) into 4.0, which is beyond my knowledge and capabilities, and so I gave it up.
I don't even know if it is planned to have a valid update path from future 3.10 (with 4.0 compatibility layer) and 4.0, or if upgrading 3.10 to 4.0 would be done with a kind of migration.
So finally I suggest to close this issue here.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

Then there is still a lot of work to be done for making that work.

1106 commits behind staging.

I wish I could help with that, but I think merging stuff from 3.9=staging into 4.0 is far beyond my capabilities.

But if someone would merge in the extensions which have been added to staging after 4.0 was branched off so that new installations of 4.0-dev would work and contain those 3.9 extensions like e.g. the privacy suite, I could help with the schema updates.

Commits need to be merged forward in order, you can't just flat out copy the new files from 3.9 to the 4.0 branch otherwise that basically completely screws over being able to merge anything (and at that point you basically have an internal product fork and all work has to be duplicated across both branches). So sooner or later the 3.9 code will end up in 4.0, but it has to be done in the right way.

Yes, and when that has happened I can help with the schema updates. Is there already a plan when this will be done?

So why publish a link to an update package that does not work?

@Webdongle Good question. Maybe @mbabker knows why? From my point of view, the update XML of J4 should not allow updates from 3.9, and maybe as long as updates from 3.10 will not work also not allow from 3.10, until this works.

So why publish a link to an update package that does not work?

Because it is supposed to work but having a constant upgrade path was obviously not chosen as a priority.

So now we have a catch 22. The update is there because it is supposed to work but report it as an isue results in a 'we dont expect it to work' type answer. So the question remains ... if it doesn't work why put a link to it? In other words why not remove the link until it works?

It should have never been allowed to be broken in the first place and
removing the link just masks the issue even more. It’d be like breaking
the updater between 3.x releases, you fix the bug and not hide it.

Before a beta can be realistically tagged the update process must be
confirmed working or the project is back in a 1.5 to 1.6 migration.
Everyone remembers how well that was received.

On Thu, Dec 27, 2018 at 10:34 AM Kevin Griffiths notifications@github.com
wrote:

So now we have a catch 22. The update is there because it is supposed to
work but report it as an isue results in a 'we dont expect it to work' type
answer. So the question remains ... if it doesn't work why put a link to
it? In other words why not remove the link until it works?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#23315 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAWfoe9IEHuwzwkvkR4eWrQk7vpEDeLxks5u9OiUgaJpZM4ZfVHp
.

--

• Michael Please pardon any errors, this message was sent from my iPhone.

removing the link just masks the issue even more. It’d be like breaking the updater between 3.x releases, you fix the bug and not hide it. Before a beta can be realistically tagged the update process must be confirmed working or the project is back in a 1.5 to 1.6 migration.

Catch 22 again. It doesn't work and every time someone reports it as an issue they get told it wont be working until xyz ... but the link must be there.

Either it works or it doesn't. If it doesn't then why not just remove the link until 'xyz' is done and the update is ready to be tested ?

"There's a hole in my bucket dear Liza a hole!!!"

The bug is a procedural issue compounded by code issues. The update process should've never been allowed to break in the first place, and there's no sane thing that can be done to say "don't update to 4.0" short of hardcoding rules into the next 3.9 releases that block the 4.0 package.

Can the links be hidden on the developer network? Sure. Should they be? I say no. I also don't want to deal with all sorts of conditional code just for 4.0 in https://github.com/joomla/developer.joomla.org/blob/master/plugins/content/nightlybuilds/nightlybuilds.php so I'd rather not start adding version specific behavioral difference for the nightly builds list.

Personally, I say fixing the updater should be a priority because you cannot tag a beta without that working and with all the architectural and repository workflow changes that have been made that is not going to be a 10-minute fix. With the project's tendencies, as soon as you start putting the update stuff out of sight and out of mind, it's going to be forgotten about.

@mbabker The problem is that for making updates of 3.9 and 3.10 to 4.0 possible, we have to change extension IDs of 4.0 extensions, because they are already used by other 3.9 (and 3.10) extensions. This would break updates within the 4.0 dev version, e.g. from alpha 5 to alpha 6 or so. If this is ok, I could make a PR to change the extension IDs within 4.0-dev, and someone who is more familiar with the 3.9 extensions (privacy suite, actions logging) could merge them later into 4.0-dev. I'd like to have your opinion on that. Thanks in advance.

The extension IDs can be fixed, that isn’t dependent on merging forward the
3.9 code to 4.0. Anything else blocking the upgrade should be ID’d and
fixed accordingly.

On Thu, Dec 27, 2018 at 4:39 PM Richard Fath notifications@github.com
wrote:

@mbabker https://github.com/mbabker The problem is that for making
updates of 3.9 and 3.10 to 4.0 possible, we have to change extension IDs of
4.0 extensions, because they are already used by other 3.9 (and 3.10)
extensions. This would break updates within the 4.0 dev version, e.g. from
alpha 5 to alpha 6 or so. If this is ok, I could make a PR to change the
extension IDs within 4.0-dev, and someone who is more familiar with the 3.9
extensions (privacy suite, actions logging) could merge them later into
4.0-dev. I'd like to have your opinion on that. Thanks in advance.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#23315 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAWfoT3oWsopS0IYYTW7VQNwc_qFyo0tks5u9T4XgaJpZM4ZfVHp
.

--

• Michael Please pardon any errors, this message was sent from my iPhone.

The extension IDs can be fixed, that isn’t dependent on merging forward the 3.9 code to 4.0. Anything else blocking the upgrade should be ID’d and fixed accordingly.

Does that mean we can change or combine the existing 4.0.0-*.sql schema updates and also delete the old and wrong 3.8.*.sql schema updates in the 4.0-dev branch? This would be necessary to make updates from 3.9 or 3.10 to 4.0 possible, but then it would break update from e.g. alpha 6 to the next alpha or beta.

@wilsonge I'd like to know your opinion on the above discussion, too.

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

closed as Issue seems to be solved.

closed as Issue seems to be solved.