Forum OpenACS Q&A: Re: Design of an "Automatic Software Update Service"

Collapse
Posted by Malte Sussdorff on
Your are forgetting some issues:

6) What happens if there is custom code. Currently the APM approach will overwrite any custom code and it's gone. As for CVS, it might generate conflicts. You could do a check if any files in the package you are about to update have been changed and if yes send the administrator a notification that the package is available for upgrade, but can't be upgraded due to changes made locally (similar to how apt-get works).

7) We have a tendency of not being very good with releasing packages, as it requires to retag the package every now and then. So the APM approach would require the developers to tag packages on a regular basis. On the other hand, if you go with the CVS approach, you might break your site even in the "stable" tree, because you are updating without dependencies (as you might depend on a function in the kernel that has been added but not resulted in a new release of the kernel package).

My recommendation therefore is this:

- Add a "sources" repository to the APM which is a list of repositories where APM can retrieve the files from.
- Use APM files instead of CVS
- Check before the upgrade if it is safe to install (we should be doing this anyway)
- Write a collector that retrieves the CVS messages between the previous release and the current one and stores them in a file "latest_release.changes" that is displayed to the user before upgrade.
- Write a TIP for it.
- Collect gratitude :).

I don't think a rollback will work, especially not an automated one. For sure you could execute a database backup in advance, but do you really want the users to loose their data because of an upgrade they did not like?

So yes, I do like your idea, but it is not the piece of cake as it might sound.