Support

Yes, I did that on purpose. Sorry, you were all part of an experiment to see if anyone is still reading the release notes. In previous versions I had left subtle inaccuracies about the supported versions and nobody bat an eyelid. In this version I decided to be more blunt with the experiment. Apparently everyone noticed when release notes went missing. That's great! It means that there is a point in spending time and energy maintaining them on every release. Thank you for your feedback and sorry for having you be my unwitting guinea pigs.

If you download the ZIP file and extract it there's the file backend/CHANGELOG.php. Despite the name, it's a plain text file which lists all the changes per release. This is the same file that ends up as the CHANGELOG part of the release notes.

The rest of the release notes is the same template text as the previous version explaining PHP and Joomla! version compatibility which, of course, does not change throughout the 5.2.x release cycle of Akeeba Backup. Of course there is no "Release highlights" section in the release notes since this is something I have to write manually every time we make a release and this time, as I explained, I didn't. Even when I did I was just summarizing the changelog. My plan is to stop writing the "Release highlights" since it's duplicate information and costs me a good deal of time (about an hour every time we release Akeeba Backup and Akeeba Solo).

I think there was some misunderstanding on what the highlights are :) These are the summary of the changelog a bit more verbose. However, whenever there's a requirement or other major change I write release note sections below the highlights. For example when Dropbox v1 was removed following Dropbox' announcement that it's no longer supported I explained this and wrote a guide on migrating your profiles as a release note section. Same thing when we change the PHP and / or Joomla! compatibility for our software. I will continue writing these. These are important.

Further to that, our view is that you must always update to the latest version. If you choose to not update contrary to our advice we can't provide support and we can't help or show much sympathy if a backup or restoration fails due to a non-adressed issue that we have already fixed in a release after the one you're using. We fix issues (mostly working around bugs in PHP itself, old versions of third party libraries used by low quality hosts to build their PHP binaries, or simply bad host setups) to protect your data. If we thought there's no compelling reason for our users to update regularly we'd only be releasing one or two versions every year and charge per version. That's a valid pricing model which has been around far longer than subscription-based pricing, see for example Microsoft products in the 80s to late 00s, or shareware software. That said, this model doesn't fit the kind of software we're making where an outdated feature, a non-addressed issue in third party code or a plain old bug could spell disaster to your data.

The only time we explicitly tell our clients not to update is when they are upgrading their site to a new Joomla! version. In this very specific use case they need to use an old version to take a backup of their site, then disable our component and its plugins, update Joomla! and then update our software. But even in this case we explicitly state that the old version branch is meant only for backing up before updating and there's minimal or no support (depending on PHP and Joomla version).

I'm sorry I had to go on a tangent regarding updates but this being a public ticket I don't want anyone to come 3-4 years later and tell me that they didn't update because they found this obscure public ticket where it seemed to them like I am condoning non-upgrading as a viable alternative. In case you're wondering: yes, that's based on a true incident.

Regarding the release notes in general, as I said, it was an experiment. I do that every year and a half or so when we release a very stable release, in a long release cycle, with no compatibility or other important changes. Basically: when it's just a bugfix release. As with previous tests the result is that I should keep writing release notes.

BTW: the idea of not writing release notes is not entirely uncommon in the software world. Have you ever tried reading the changes for the Facebook or Twitter apps on iOS or Android? Yup. Nothing. On the other extreme you have apps like Slack or 1Password with funny and enjoyable changelogs. I'm trying to find what is useful and to whom because I don't personally find either extreme very helpful but I'm not my users ;)