Support

Akeeba Backup for Joomla!

#8718 Last actually 'stable' Stable Release

Posted in ‘Akeeba Backup for Joomla! 4 & 5’
This is a public ticket

Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.

Environment Information

Joomla! version
n/a
PHP version
n/a
Akeeba Backup version
n/a

Latest post by nicholas on Wednesday, 24 November 2010 07:33 CST

user6628
I have a question,

What is everyone's opinion about the last actually stable release of akeeba backup and kickstart?
I recently tried to use the latest version of each and got erratic results - not sure what is really stable, since latest version seem to be going backward in .

I am hoping to save some time by getting advice about what actually works - so I can skip trial and error.

So far, the last stable version of Kickstart was 3.1.1
and the last stable version of backup is 3.0.1.

Thanks,

Sean

nicholas
Akeeba Staff
Manager
Kickstart 3.1.1 has grave bugs regarding the FTP mode. Kickstart 3.1.5 is really the most stable release. If you use anything less, you're on your own.

Regarding Akeeba Backup, 3.1.4 has a bug in the ZIP archiver and the auto-updater feature. An update is planned for today (assuming that I can finish up with the support requests). Akeeba Backup 3.1.2 is really stable. The only known bug in that release is a cosmetic issue (extraneous warnings issued on Windows hosts). The versions you are using, 3.0.1, has high priority bugs. If you want to use that's fine by me but I can't support you if you have any backup or, most importantly, restoration issues.

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!

user6628
Thanks for your reply.

I grabbed 3.1.5 and upgraded a site - and I hope it works. The point I am trying to make is that 3.1.4 should not have been released as 'stable' when clearly it wasn't. I recommend revising release descriptions to include some candidacy for stable that has to be earned by user testing.

I don't mean to be critical, I think this will help clarify which version a person should use if they just want it to work without question.

Thanks

nicholas
Akeeba Staff
Manager
OK, I didn't want to make an issue out of it, but here how the story goes. I had released three betas and an RC of 3.1. Nobody reported any grave issues with the RC for almost a month, so I proceeded to release 3.1 stable. Guess what? People started reporting bugs which they had found during the betas and RC but never reported, in the hopes that they would magically disappear. This made me have to fix them as soon as possible, because the version was released as stable. I had already branched out the code to start working on 3.2 when people started reporting bugs with Windows-based servers (which sadly account for 20% of the Internet). So, I had to fix them. In the process, another bug was triggered, which could potentially kill a suPHP-based site, something which regular testing failed to catch.

Now, I knew that the updater wasn't tested and the ZIP archiver was also not tested. I had two options: a. screw everybody using suPHP or b. release early, fixing this major issue, and run regular testing and bug fixing to get the ZIP archiver and the updater working. I chose the former, which I honestly think was the best approach. In fact, I had to stay awake for 24 hours in order to fix it and release the new version, but I didn't bother mentioning it.

The bottom line is that as long as people do not report bugs when the product is in alpha, beta or RC stage the stable releases won't be stable for all. An unreported bug can't be magically solved. I mean, even mega-corporations like Microsoft release products with bugs because nobody reported them during the CTP and beta periods. All I can do to counter that is to simply choose to add more testing rules in my usual testing procedures to catch failure cases discovered in past releases.

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!

Support Information

Working hours: We are open Monday to Friday, 9am to 7pm Cyprus timezone (EET / EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets outside of our working hours, but we cannot respond to them until we're back at the office.

Support policy: We would like to kindly inform you that when using our support you have already agreed to the Support Policy which is part of our Terms of Service. Thank you for your understanding and for helping us help you!