Das sieht bös aus, beim Aufrufen von mAirlist kommt folgender Fehler:
Mit der neuen 2.0.6? Einfach so? 
Mailst du mir mal deine Config?
Torben
Ist raus.
Liegt an deiner skin.ini. Da ist eine Zahl zuviel bei den “ColWidths”-Einträgen. Hast du evtl. eine skin.ini von Version 2.1 genommen? Da gibt es ja inzwischen eine Spalte mehr …
Ja, definitiv. Ich stecke aber auch nicht so in der Sache mit der Durchnummerierung der Versionen drin. Sehe ich das richtig, das 2.0.6 nicht alle Funktionen von 2.1.6 hat? 
Aber 2.1.7 wird dann auch die Bugfixes von 2.0.6 enthalten? Nicht ganz einfach!
Hm, wie soll man das erklären …
Stell dir die Versionen von mAirList wie einen Baum vor. Ich zeichne mal einen Ausschnitt davon:
...
|
2.1.6
|
2.1.5
|
2.1.4
|
2.1.3
|
2.1.2
|
2.1.2
|
2.1.0
|
2.0.0 - 2.0.1 - 2.0.2 - 2.0.3 - 2.0.4 - 2.0.5 - 2.0.6
|
1.5.56
|
1.5.55
|
1.5.54
|
...
Die Entwicklungs-Versionen (mit ungerader Zahl in der Mitte) bilden den Stamm. Bis vor kurzem war das Version 1.5. Wenn irgendwann die Zeit gekommen ist, alle gewünschten Features drin sind und augenscheinlich keine Bugs mehr vorhanden sind, wird der Zustand in Form einer stabilen Version eingefroren. In diesem Falle Version 2.0.0. Danach geht die Entwicklung dann mit 2.1.0 weiter. Wer ein stabiles System (so gut wie) ohne Fehler haben will, verwendet dann Version 2.0, wer die neuesten Features und Bugs will, nimmt Version 2.1.
Treten nun im Laufe der Zeit Fehler in der Version 2.0.x auf, muss ich die natürlich schnellstmöglich reparieren. Denn das ist ja der hochgelobte stabile Release. Also nehme ich den Sourcecode von Version 2.0.0, repariere den Fehler, und lade das Ergebnis als 2.0.1 hoch. Beim nächsten Fehler dann 2.0.2 usw. So wächst an der Stelle, wo die Version 2.0.0 ist, ein “Ast” (man redet auch tatsächlich von “branch”). Neue Funktionen kommen aber in den 2.0-Ast nicht mehr rein, höchtens Kleinigkeiten, die sich ohne großes Testen gefahrlos integrieren lassen.
Wenn ein Fehler im 2.0-Ast gefunden wurde, ist es natürlich sehr wahrscheinlich, dass er auch im 2.1-Stamm enthalten ist. Dann muss er auch dort repariert werden.
Bei dem ganzen Versionsdurcheinander hilft mir übrigens eine Software namens “Subversion” (SVN). Dort werden sämtliche Änderungen am Sourcecode nachgehalten, man kann nach dem Hochladen die gerade aktuellen Versionen mit der Versionsnummer “markieren” und den Zustand später wiederherstellen, wenn man mal einen Fehler sucht oder so. Außerdem ist die Software in der Lage, Änderungen an einem Ast in einen anderen zu übertragen. Wenn ich also im 2.0-Ast einen Fehler behebe, kann ich die notwendigen Änderungen am Sourcecode mit einem Mausklick auch in der aktuellen 2.1er-Version beheben. Genauso könnte ich eine kleine Verbesserung, die in der Version 2.1 neu eingebaut und getestet wurde, in den 2.0-Ast rüberkopieren. So ist es gerade aktuell mit den Sortierfunktionen in der Eventliste geschehen.
Torben
Danke für die ausführliche Erklärung. Jetzt ist mir einiges klarer…