WIP: Release configuration updates script #193

Inspired by the problem which arose in discussion of PR TDE/tdelibs#129.

This bash script can be used to make some modifications to existing configuration files when upgrading to a newer release.

When run without arguments, it checks whether the user has updated to a newer release (not unlike tde_release_notes) and if so, it can run some commands in order to ensure that some changes in this release are usable without user intervention.

The commands for each release are put into this script itself.

The script supports multiple version upgrades and some custom options.

For an example of how this is useful see the problem in TDE/tdelibs#129 and lines 14 to 21 of this script.

I think it's a versatile enough approach reusable in similar cases.

I'd like to hear your opinions on this.

This seems unnecessary. For such updates, whether configuration or performing all kinds of renaming and other steps, the r14-xdg-update script has been here for a long time. Therefore, it seems unnecessary to add another script for a very similar purpose. This script instead of the version number uses the data-derived identifier. This provides usability not only for the final releases, but also during development (such as R14.1.0) as well as preliminary packages of stable releases.

I didn't know about r14-xdg-update or more precisely what purpose it served. I thought it had something to do with 3.5->R14 migration. Glad to know that such infrastructure is already in place ;-)

Should I add the change needed for #1 and TDE/tdelibs#128 into r14-xdg-update then?

It probably makes sense to add a short section in r14-xdg-update as Slavek's suggested, since that script is already run at each login and though the infrastructure is already in place. The initial purpose of r14-xdg-update was for safely migrating from 3.5.13's .kde to R14's .trinity structure. Over time we added additional functionality into it and tdelibs#129's case fits nicely there.

Having said that, it's a pity to see such effort in this PR going to waste, but yes, it's a bit overkill for what we need 😓

Don't forget to change SCRIPT_VERSION on top of r14-xdg-update (format is yyyymmddx where x is a progressive number starting from 0 in case there are multiple changes to the file on the say day.
The sed check should be executed conditionally to the script version. You can see inside the script how the other checks are done. This is to ensure those checks/renbames are executed only when needed and not all the times a user login.

Hi Philippe, did you close this because you intend to replace the PR with a separate one? In such case can we delete this branch?

Otherwise you could reuse PR and branch and force push a commit in place of the previous one.

Yes, I thought this would be more appropriate because of the branch name. I think pushing the change to a new branch named issue/1 would be better.

Yes, I thought this would be more appropriate because of the branch name. I think pushing the change to a new branch named issue/1 would be better.

Actually the branch name is not that important, since the branch will get deleted in the end after merging and there will be no "merge commit" message with the way we merge PRs. But it is perfectly fine to create a new PR for that.