Alex,
Would it be possible to do something like:
updater2.0-2.1.tar with just the changed files?
This would help a lot of people who don't want to upload and manage the large files. It would also prevent accidental overwriting of config and templates during this sort of upgrade.
Config updates can be handled by running the "reset to default" right?? That way people are aware of any changes they have to put back.
Templates can be explained, since new templates could be added (as long as the user didn't have an existing one) and old templates could be manually updated.
Or, better yet, add a new subdirectory to the templates "template", where the "stock" bare-bones set of templates would always be. Since the "default" is the "active" (and thus edited directory) having the stock set that could be checked for missing tags would be extremely beneficial.
Or, keep "default" but add a configuration parameter for the template set to use. By default it defaults to a "SiteName" directory where the "default" templates are copied. Then, "default" becomes the "stock"templates, and "SiteName" becomes the current "default"
Not very difficult changes, but it will prevent a lot of user frustration due to accidental over writes! How many people _really_ keep backups??
If you unzip the "updater" in the /updates subdirectory, the program will read your defaults and install the new codes automatically.
If you wanted to be really tricky, it would run a 'diff' against the known code, and let the user know "Changes to the existing "module.pm" may have been made, overwrite or backup? If the backup is made with the version number ie: 20, .21.,etc, then there is no way of accidentally "rolling" the backups off on a second install.
Just some thoughts about protecting users from themselves :)
PUGDOGŪ
PUGDOGŪ Enterprises, Inc.
FAQ: http://LinkSQL.com/FAQ
Would it be possible to do something like:
updater2.0-2.1.tar with just the changed files?
This would help a lot of people who don't want to upload and manage the large files. It would also prevent accidental overwriting of config and templates during this sort of upgrade.
Config updates can be handled by running the "reset to default" right?? That way people are aware of any changes they have to put back.
Templates can be explained, since new templates could be added (as long as the user didn't have an existing one) and old templates could be manually updated.
Or, better yet, add a new subdirectory to the templates "template", where the "stock" bare-bones set of templates would always be. Since the "default" is the "active" (and thus edited directory) having the stock set that could be checked for missing tags would be extremely beneficial.
Or, keep "default" but add a configuration parameter for the template set to use. By default it defaults to a "SiteName" directory where the "default" templates are copied. Then, "default" becomes the "stock"templates, and "SiteName" becomes the current "default"
Not very difficult changes, but it will prevent a lot of user frustration due to accidental over writes! How many people _really_ keep backups??
If you unzip the "updater" in the /updates subdirectory, the program will read your defaults and install the new codes automatically.
If you wanted to be really tricky, it would run a 'diff' against the known code, and let the user know "Changes to the existing "module.pm" may have been made, overwrite or backup? If the backup is made with the version number ie: 20, .21.,etc, then there is no way of accidentally "rolling" the backups off on a second install.
Just some thoughts about protecting users from themselves :)
PUGDOGŪ
PUGDOGŪ Enterprises, Inc.
FAQ: http://LinkSQL.com/FAQ