Superseding an Add-on
Permalink
I've got a simple add-on ('Back Up Files') at
https://www.concrete5.org/marketplace/addons/back-up-files...
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 athttps://github.com/concrete5/concrete5/issues/571)....
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.
Questions:
. 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.
https://www.concrete5.org/marketplace/addons/back-up-files...
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 athttps://github.com/concrete5/concrete5/issues/571)....
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.
Questions:
. 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.
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...)
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...)
If you let us know when ready, we can pull it back into the PRB, review and reapprove.
Thanks again. I'll do that.
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.
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.