You have hit a Joomla! bug. Akeeba Ltd does not publish Joomla. As a result there is nothing for us to fix. Please file a bug report with Joomla.
Akeeba Ltd is forced to use Joomla's built-in extensions updater. If we don't, the terms of service of the Joomla! Extensions Directory (JED) stipulate that our software will be unlisted from the Directory anywhere between 1 month to forever.
More specifically, the update to all our Joomla software is handled in whole by Joomla's built-in extensions updater which is a feature of the com_installer (a.k.a. "Extensions") component which is part of Joomla itself.
Akeeba Ltd only published the XML update stream on its CDN. The XML update stream correctly identified the 6.0.0.b1 version as a
Beta. This is the only item in the update process under our control and it's correct. The XML Update Stream is public information. You are free to examine it and verify the accuracy of my claims.
Joomla will periodically download the XML update stream. The frequency of that check is determined by Extensions, Manage, Update, Options, Updates Caching (in hours) and how often you visit your site's administration backend. When Joomla determines this information is out of date it will fetch this XML file and parse it. The file has a list of all currently published versions of our software along with their stability level and Joomla compatibility. On each and every one of them Joomla will check that the current version of Joomla is supported
and that the stability level of the available version is higher than the configured (Extensions, Manage, Update, Options, Minimum Stability) minimum stability level. If either of these checks fails the available version record is disregarded, i.e. it's as though it has never existed for all of Joomla's extensions updater intents and purposes. Then
and only then it checks whether this version record is a more recent version than the one currently installed. If at the end of the process for all records there's a version newer than the currently installed found the update information is written to the #__updates database table which is used to render the information on the Extensions, Manage, Update page.
Please keep in mind that Joomla! may cache the update information for up to 24 hours. Therefore after changing this setting you must click on the Clear Cache and Find Updates buttons, in this order, to force Joomla! to refresh the update information. However, if you have turned on Cache in your site's Global Configuration you have to Clear Cache first, then click on System > Clear Cache from the top menu, then go back to Extensions, Manage, Update and click on Find Updates again. I know this is completely inane, but I was not the person who decided to design com_installer like that.
Finally note that I have tried the update steps with Joomla! 3.8.3 and 3.8.4 with Akeeba Backup 5.6.2 installed. When the Minimum Stability is set to Stable only 5.6.3 is reported and installed. After its installation no more updates are found. When the Minimum Stability is set to Beta then 6.0.0.b1 is reproted and installed. I would like to point out that not only I tried this process on testing and live sites (including our own live site where you filed this ticket and all of my personal sites) but I also tried this on three different development sites. On the development sites I stepped through the code to make sure that what happens is really what I described. It is. Our XML update stream marks the release as beta and Joomla DOES see it's a beta and DOES take it into account.
Therefore what you observe seems to be an old installation of Joomla, an installation of Joomla not properly upgraded to 3.8.4 (some files did not get written?), or a very weird bug affecting only some servers. In any case, there is nothing for us to fix since we are not publishing Joomla and we do not manage your site or your server. The only thing in the update process that's under our control (the CDN update stream) works perfectly. The downloads on our site
OF COURSE work perfectly. God forbid we delivered random files!
So, back to your point. Yes, you're paying us so we can develop and maintain
our own software and services. We do. Your problem is NOT with our software or services. It might be with Joomla, but my debugging sessions and my visits to affected sites tell me there's a near certainty that your issue is with the Minimum Stability setting, update caching or an outdated Joomla! version. In any case, it's nothing under our control so what exactly do you suggest we should "fix"? The CDN update stream which is already correct? The downloads which serve the correct files? Or people's sites which we didn't build nor configured? Please clarify what you have in mind.
In any case, you have no idea how much testing goes into a new version before releasing it. Our "beta" versions are actually stable. We only use the "beta" tag to entice people to put the new version through its paces, uncovering any small issues we might otherwise never hear about for months or years. We didn't expect that some Joomla installations would drop the ball
despite us doing everything right.
So let me tell you what I'm going to do on Wednesday. I'm going to take the exact same code as 6.0.0.b1 with a minor visual tweak and release it as 6.0.0 Stable. I hope that makes everyone happy. The only reason I can't do this today is that I'm not at the office and my Internet connection here seems to drop randomly. Good enough for replying to tickets, bad enough to make releasing software a massive pain in the posterior.
Oh - and if I can make a request, bake in scheduling somehow. I know I can cron the command line, but a great visual interface would rock and be worthy of a 6.0 major release number.
You are thinking about the Lazy Scheduling Plugin we had back in 2011. Please do take a look
at the very old documentation of the 3.4 release under section 5.4. I have listed 14 reasons why this won't work properly on a site. Items 4 and 6 have been mostly but not fully solved following the re-architecture of the backup engine in version 5 - there are still some ways they can cause a problem. The points 7, 11 and 13 are actually very significant and put the final nails to its coffin.
7. Use of a hidden IFrame. Since circa 2015 this is typical behavior of malware. Browsers and Internet security solutions (browser extensions or standalone applications) block or report it. Basically, your site will appear to be malicious.
11. Parallel run of the same backup step. This is something that cannot be avoided as the lock mechanism, be it database or filesystem, has a delay between write and read. The only way to work around that is adding a 1 second delay which means that your page load time increases by that much. 1 second delay was not a bug deal in 2011 with 10 second page load times but it's a massive deal in 2018 with 0.5 seconds page load times. More so when your site gets penalized by search engines for being slow to load.
13. System - Cache breaks the plugin. Since the scheduling plugin relies on outputting something to the browser only on
SOME pages, page caching is incompatible with it.
The only solution to most of these issues is running the backup step before the page is rendered by the browser, in Joomla's onAfterInitialize event. This means that you will have page load times between 10 to 40 seconds, making your site unusable and increasing your bounce rate. At the same time, tying your backup to user visits (which tend to modify the filesystem and database data) is the best way to end up with issues upon restoration. So, if you ask me, this is a rather reckless -if not outright daft- way to go about scheduling backups. There's a reason there is CRON and there's a reason we tell you to use it.
Nicholas K. Dionysopoulos
Lead Developer and Director
🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!