Superseding an Add-on

I've got a simple add-on ('Back Up Files') at
This comprises a single job that, unsurprisingly, makes a back-up copy of a site's files (except database).

I've now developed a second job that makes a downloadable copy of the database. (It uses mysqldump and actually complies with most of the recommendations at

I think the best way to package this as an add-on is to put both jobs into the one package. I'm wary of combining them into one job for fear of falling foul of php's max_execution_time. The new add-on should have a new name to better indicate its broader scope ('Simple Backup'?). A new package name and handle should be consistent with this.


. The PRB wouldn't need to reconsider the backup-files job because it has already done so. Is this manageble?

. For saner version control, I'd like to remove the original 'Back Up Files' add-on from the marketplace. However, this would leave current users with no obvious upgrade path if bug-fixes are implemented in the new package. Is there a way of prompting all extant users to install the new add-on? The only thing I can think of is to release a final version of 'Back Up Files' that announces that it's been superseded. Ugly.

View Replies: View Best Answer
JohntheFish replied on at Permalink Best Answer Reply
If you can live with keeping the package handle the same, you can give the existing package whatever new name you like in the package and in the marketplace. You can have more than one job in the package, so you could re-write the marketplace for the new package, point out to users this supersedes the old package, and that the old job is included for backward compatibility.

The new package would go through the linter, but would already be in the marketplace, so would not automatically go to the PRB.

If you decide to submit a new package with a new handle, the marketplace has no mechanisms for automating what you suggest.
Gondwana replied on at Permalink Reply
Thanks Mr theFish. I did think of keeping the package handle the same but I didn't think the PRB would wear it. The handle (gond_backup_files) is still defensible at a stretch when the database capability is included, and as a concession for legacy reasons.

Perhaps the main problem with keeping the same package handle is that the new version would bypass the PRB and go straight to the marketplace. This might seem strange, but I'd welcome PRG scrutiny! The code changes are very significant, the backup function is important to get right, and I'm a dodgy programmer.

Is there any way to get PRB scrutiny on a new version with the same handle prior to marketplacing? If the 'system' doesn't support this, could I distribute packages for review informally?

(The add-on will remain free, so I'm not in this for $. I think a quick-and-easy backup feature is something that c5 should have. Your average user/designer shouldn't have to do CPanel/phpmysql to create a routine backup. Restoring is another matter...)
JohntheFish replied on at Permalink Reply
If you let us know when ready, we can pull it back into the PRB, review and reapprove.
Gondwana replied on at Permalink Reply
Thanks again. I'll do that.
Gondwana replied on at Permalink Reply
I think i'm ready. I haven't uploaded the new package yet, just in case it would go live straight away. Please let me know when it's safe for me to do so.