Sie sind hier

Wie wichtig ist bei zukünftigen KOMA-Script-Versionen Kompatibilität zu früheren Versionen?

Unabdingbar
16% (10 Stimmen)
Sehr wichtig
25% (15 Stimmen)
Wichtig
23% (14 Stimmen)
Nicht so wichtig
30% (18 Stimmen)
Unwichtig
7% (4 Stimmen)
Gesamte Stimmenzahl: 61

Kommentare

Ich fände eine Kompatibilität schon relativ wichtig, würde diese aber abhängig von den einzelnen Funktionalitäten sehen. Eine Inkompatibilität nehme ich gerne in Kauf, wenn KomaScript dadurch entscheidend verbessert wird - da dies ohne Zweifel Ziel jeder Weiterentwicklung ist, wird es sich vermutlich nicht (ganz) vermeiden lassen.

Vielleicht gibt es ja die Möglichkeit eine "Kompatibilitätsmodus" zur Verfügung zu stellen, aber selbst darauf könnte ich persönlich verzichten.

Zur Frage eines Kompatibilitätsmodus gibt es eine weitere Abstimmung.

Das Problem mit solchen Schaltern ist, dass irgendwann niemand mehr alle möglichen Einstellungen testet. Aus dem Grund ist vor einiger Zeit die Kompatibilität zu Script 2.0 (LaTeX2.09-Vorgänger von KOMA-Script) komplett rausgeflogen. Da ich selbst kein Script 2.0 mehr installiert habe, war ich auch selbst nicht mehr in der Lage zu testen, ob im Kompatibilitätsmodus das Verhalten von KOMA-Script gleich ist.

Außerdem lesen Anwender üblicherweise keine Anleitung. Wenn dann irgendwo steht, dass ein bestimmtes Feature nur verfügbar ist, wenn man mit der Option version die Kompatibilität min. auf Version 2.9873 einstellt, dann wird genau das ignoriert und es gibt tonnenweise Supportanfragen, warum das Feature nicht geht. Genauso kommen irgendwann Fragen, ob man nicht die Möglichkeit X mit der Möglichkeit Y kombinieren kann, obwohl Möglichkeit X nur bis Version Q und Möglichkeit Y erst ab Version V zur Verfügung steht und ab Version W Möglichkeit Z sich mit Möglichkeit X nicht verträgt wobei Q < W < V gilt. Wobei ich erst einmal die Anforderung verstehen muss, um dann auf ein schlichtes "Nein" Unmut zu ernten.

Dass ich Kompatibilität nicht leichtfertig aufgebe, ist klar. Aber es gibt auch Dinge, die eigentlich Bugs sind, deren Beseitigung aber zu Inkompatibilitäten führen. Braucht es dafür dann einen Schalter? Ich habe dazu zwar selbst eine klare Meinung, aber mich würde mal interessieren, wie andere das sehen. Dabei sind eigentlich die Stimmabgaben, die einfach ohne langes Nachdenken erfolgen, für mich die wertvollsten, weil sie ziemlich genau die Grundstimmung wiedergeben, die mir allgemein begegnet.

Bild von JuergenFenn

...um welche Features bei welchen Dokumenten es geht.

Ich habe mein Briefpapier jetzt mit mehreren lco-Dateien, einer adr-Datei und einer Vorlage auf scrlttr2 aufgebaut -- scrlttr2 sollte deshalb bitte möglichst auch in künftigen Versionen so funktionieren wie gehabt. Hier wäre unbedingt Stabilität wünschenswert, weil man sonst nach jedem Update meine lco's immer parallel zu KOMA-Script weiterentwickeln müßte.

Etwas anderes sieht es sicherlich bei Artikeln, Büchern usw. aus, die ich später neu kompilieren möchte. Wenn man hier den Quellcode aufhebt, wird man alle cls- und sty-Dateien ohnehin mit archivieren.

Im übrigen dürften neue Funktionen oder Optionen oder Default-Einstellungen nicht weiter stören.

Genau Deine Argumentation für Briefe, kann ein anderer mit gleicher Begründung für andere Klassen bringen. Es gibt durchaus Leute, die Wrapperklassen um KOMA-Script packen. Für die gilt generell genau dasselbe wie für lco-Dateien. Im Prinzip dienen lco-Dateien nur dazu, Wrapper-Klassen, die keine eigenen Optionen benötigen, überflüssig zu machen. Wobei das mit den eigenen Optionen auch relativ ist, nämlich dann, wenn man damit zufrieden ist, Optionen nicht über \documentclass, sondern erst später mit keyval-Methoden zu setzen.

BTW: Witzigerweise gab es im Beta-Test bereits eine Überraschung wegen eines alten Features, das aber nur vorhanden sein kann, wenn die Kompatibilität nicht herunter gesetzt ist (beispielsweise mit version=last). Dass es sogar mich verwirren kann, dass die Kompatibilität explizit ausgeschaltet, statt explizit eingeschaltet werden muss, ist nicht unbedingt ein gutes Zeichen. Es ist aber so dokumentiert. Eine Änderung dieses Umstandes wäre also bereits eine inkompatible Änderung.

Bild von JuergenFenn

Natürlich denkt der gute Mann an sich selbst zuerst. ;-)

Eine optimale Lösung für das Problem, das Du formulierst, kann es nicht geben. Es ist immer eine Wahl zwischen Pest und Cholera. Nur wenn man nie mehr etwas ändern täte, bliebe alles, wie es ist. Nur: Will man das wirklich? Und bliebe dann wirklich alles, wie es ist, wo sich doch die Welt drumherum ständig ändert?

Tempora mutantur, also auch KOMA-Script. Meine 2ct, wo es mich am meisten stören würde, habe ich beigetragen... ;-)

Ich kann da nur zustimmen. Kurzfristig werde ich mich vielleicht über Inkompatibilitäten ärgern und auch der Aufwand ist natürlich nervig, vorhandenes anzupassen.
Trotzdem finde ich, ist es langfristig wichtiger Bugs zu beseitigen. Wie ich bereits sagte, Bugbeseitigung und wichtige Verbesserung finde ich wichtiger als Kompatibilität - sofern die Kompatibilität nicht leichtfertig aufgegeben wird, was aber, wie du klarstellst, nicht der Fall ist.

Hallo,
ich sehe es wie Markus...die Nutzer lesen selten die Anleitung. Mir ist eigentlich "nur" eine einheitliche Syntax und sinnvolle Bezeichnungen wichtig.

Grüße
Manuel

PS: Klingt etwas radikaler, wie es gemeint ist...Markus hat ja schon erwähnt, dass er versucht Inkompatibilitäten zu vermeiden.

PPS: Sehe erst jetzt, dass das ja schon eine ältere Umfrage ist!

Die gibt es zwar schon lange, aber bisher gibt es noch nicht einmal 50 Stimmen dazu.

Comments for "Wie wichtig ist bei zukünftigen KOMA-Script-Versionen Kompatibilität zu früheren Versionen?" abonnieren