Overwriting policy in upgrading

Cantor, Scott cantor.2 at osu.edu
Mon Dec 19 12:55:27 EST 2016


> I also imagined the feasibility of a script. It should:
> 1. update unmodified configuration files
> 2. remove unnecessary unmodified configuration files
> 3. suggest distribution changes for modified configuration files
> 4. suggest removal of unnecessary modified configuration files

Scripts can be "easy", but cross-platform scripts are not, so everything we do of that nature typically becomes twice the work that it might for a specific group that doesn't have to support Windows or only has to support Windows. Just something to bear in mind.

> In this investigation, I found it needs another information to check
> distribution changes for configuration files in webapp/, e.g. web.xml. Of
> course I can compare current settings (in edit-webapp/) and new distribution
> default (in INSTALLER/webapp/), but it is not enough to merge customization
> and distribution change.

We got the webapp merge backwards, so until we do 4.0 (and if we're willing to change this then), we're stuck with the fact that people's custom changes end up in webapp/ and have to be adjusted at times.

> In short, I think (old) distribution defaults should exist in dist/webapp/.

I think that's just an artifact of the mistake we made with the direction of the webapp merge, though I think in the end it just makes more sense for now if you care that much to keep the original installation files around.

While I appreciate that people want everybody's installs to be "clean", I think that's just ultimately unrealistic once a system gets into production. The webapp thing is just a bug but the rest is something we're deliberate about. You do not have to merge in changes unless you need to enable a feature that wasn't in the version you originally installed, and we do try to document the changes required to enable something of that sort.

We almost never remove a file unless we're talking about a major upgrade. The messages files are among the very few examples I can think of.
 
I appreciate that consistency makes support easier, but I just don't think it's common enough. Most of the time people either edit the files and make it impossible to automate these changes you would be trying to make, or they're operating the software in such a limited way that they wouldn't care about the new features anyway.
 
-- Scott



More information about the users mailing list