Software ist nicht perfekt und wird auch ständig weiter entwickelt. Das führt dazu, dass bestimmt Konfigurationen der Software sehr viele Generationen überleben müssen. Problem dabei ist, dass durch neue Erkenntnisse Defaults geändert werden, neue Parameter notwendig werden, und dass es eben generell schwer ist den Benutzer bei Upgrades zu unterstützen:
- Welche Parameter müssen hinzugefügt werden
- Welche Defaults haben sich geändert
- Für welche Version ist die Konfiguration
Eine gute Möglichkeit ist es einen Versions-Identifier in den Dateien mitzuführen, und bei jeder (nicht kompatibler) Änderung diesen hochzuzählen.
Anwendungen haben dann die Möglichkeit entweder den Start zu verweigern, bis das Konfigurationsfile angepasst wurde, oder sich wie die alte Version der Anwendung zu verhalten.
Welche alternative Strategien existieren? Nun eine Möglichkeit ist die Konfiguration der Anwendung zu trennen in Defaults (vom Hersteller) und Änderungen (installationsspezifisch). Damit kann der Hersteller neue Defaults ausliefern und muss nicht ermitteln welche Parameter der Anwender geändert haben möchte. Der Nachteil dabei ist allerdings, dass der Anwender sich natürlich auf bestimmte Defaults verlassen hat, und wenn diese geändert werden (typisches Beispiel: der Default für einen wenig benutzen Netzwerk Server wird von "on" auf "off" gendert. Der Anwender hatte in seiner Konfiguration die Option nicht überschrieben, da der Default ja OK war. Nach einem Update der Software kommt es zu einem Funktionalitätsverlust, weil der Benutzer nicht dazu agehalten wurde, sich über die geänderte Sematik zu informieren.
Somit bleibt so oder so nur eine ausführliche Dokumentation der Änderungen. Üblicherweise geschieht dies in Release Notes, die zu umfangreichsind um die wichtigen von den unwichtigen Informationen zu trennen. Deswegen ist für den Anwender dabei hilfreich eine Versionsnummer zu sehen, die sein File aktuell hat, die von der Anwendung erwartet wird, und welche Änderungen dazu notwendig sind.
Angenommen wir haben folgendes initiale File:
# /etc/conf
Version=1
# netserver=off
basedir=/root
Beim Start einer neuen Software Version gibt es folgende Fehlermeldung:
Das Konfigurationsfile /etc/conf besitz die Version=1. Diese Anwendung benötigt die Version=4. Bitte nehmen Sie die notwendigen Änderungen anhand des kommentierten Templates /etc/conf.sample vor.
# /etc/conf.sample
basedir=/var
loglevel=4
# Versions
# 1 Initial Version
# 2 Added required Parameter loglevel (0-5)
# 3 Changed Default for netserver=on to off
# 4 changed default for basedir to /var
Version=4
Damit bleibt dem Anwender jetzt die Möglicheit sein Logfile folgendermassen anzupassen:
# /etc/conf
Version=4
basedir=/root
netserver=on
loglevel=0
Denn, er hat den neuen Parameter
loglevel hinzugefügt, hat den
netserver Parameter dessen Default sich geändert hat überschrieben mit dem benötigten Wert damit die Netzwerk Funktionen weiter bereit stehen. Die Änderung des Defaults für das
basedir kann der Anwender bewusst ignorieren.
D.h. er weiss, dass er das Default für netserver überschreiben muss um die Funktionalität zu erhalten, und dass er den loglevel parameter angeben muss. Er entscheidet sich dafür sein basedir beizubehalten. Durch die Modifikation des version= parameters signalisiert der Administrator der Anwendung, dass er sich mit dem Upgrade befasst hat.
Das ganze läßt sich nicht nur auf Konfigurationsfiles anwenden, sondern auch auf andere Objekte die eine bestimmte Sematik eines Containers voraussetzen. So werden IT-Systeme deutlich besser über längere Zeiten pflegbar.
Ich finde es schon sehr anmaßend au
f derartige Anschreiben "negativ" z
u reagieren (und diese zu verspotte
n). Ansch [...]
ROTFL - ja auf die Idee diese Blind
bewertungen abzusagen bin ich noch
garnicht gekommen .) Ist das jetzt
unhöflich [...]
Anbei ein Antwortschreiben, ebenfal
ls um einige Gedanken ergänzt.
S
ehr geehrter Herr Bewerber,
viel
en Dank f [...]
Schade, ich mag das Interface von G
Mail, aber ich brauche diese Filter
, um Catchall-Konten zu sortieren..
.
Ich [...]
LoL hätte nicht gedacht das die den
schwachsinn wirklich einführen. Au
ßerdem könnte ein Betrunkener das F
eature au [...]
Tip: GMail auf Englisch umstellen,
dann hast du die neuen Features sch
on Monate vorher.
Sehr lustig das Bild aber leider wi
rklichkeit in vielen Unternehmen...