Basierend auf einem Draft von Dethix.
Immer wieder kommt es zu Problemen, die durch unterschiedliche Ruby Versionen verursacht werden. Die Entwickler werden dabei gezwungen, viel Zeit und Energie in eine möglichst große Kompatibilität zu investieren. Dies treibt jedoch die Kosten in die Höhe, erweitert die Komplexität der Software und behindert die technische Weiterentwicklung.
PCs sind komplexe Systeme wie beispielsweise Autos. Wenn nun jemand sagt, wieso funktioniert deine Ruby Bibliothek nicht mehr mit 1.4, 1.6 oder 1.8, dann kann kann man eigentlich nur entgegnen, dass Softwareupdates ein elementarer Bestandteil dieses “komplexen Systems” sind. Nur weil etwas mit einer bestimmten Konfiguration heute funktioniert, heißt das nicht, dass es auch morgen noch so ist. Als Beispiel kann man dabei wieder das Auto anführen. Dort ist es selbstverständlich, dass man regelmäßig den Ölstand überprüft. Tut man es nicht, wird man früher oder später Probleme mit dem System bekommen, das Auto fährt nicht mehr. So ähnlich, leidet Software dabei unter virtuellem Verschleiß. Zwar wird keine Ressource verbraucht oder ändert sich über die Zeit, aber das System und die Technik auf der sie installiert ist und eingesetzt wird, wandelt sich. Neue Technologien erscheinen und lösen nach und nach ältere ab. Der Vergleich mit dem Auto mag etwas hinken, aber er macht deutlich, worauf ich hinaus will. Ohne Software Updates wird man zwangsläufig irgendwann auf Probleme stoßen.
Nun kann man argumentieren, dass man nicht auf jede neue Technologie aufspringen möchte und sich vielleicht bewusst dagegen entscheidet. Das ist natürlich jedem selbst überlassen. Allerdings muss man sich dann auch darüber im Klaren sein, dass man mit den Konsequenzen leben muss und nicht andere dafür verantwortlich machen kann.
Einen wichtigen Aspekt aktueller Software vergessen dabei aber viele. Neben dem zu erwartenden Zuwachs an Funktionalität gewinnt man außerdem eine erhöhte Sicherheit. Regelmäßig werden mit Updates Sicherheitslücken geschlossen, die Stabilität erhöht, die Performance verbessert und das Userinterface aufgrund von neuen Erkenntnissen optimiert.
Auch technisch weniger versierten Benutzer sollte somit das, auch aus dem wirtschaftlichen Bereich bekannte Paradigma “Nichts bleibt wie es ist” vermittelt werden. Nur so lässt sich sicherstellen, dass aktuelle Software als etwas selbstverständliches und notwendiges erkannt wird.
Neben den Nutzern der Software muss man aber auch an die Entwickler appellieren. Diese müssen dafür sorgen, dass einfache und für jeden verständliche Updatemechanismen in ihrer Software integriert werden, mit der auch jede Hausfrau, die sonst nichts mit Technik am Hut hat, klar kommt. Dabei wandelt man aber auf einem schmalen Grat. Zum einen muss der Benutzer weiterhin Herr über sein System sein und jederzeit selber entscheiden können, was auf diesem passiert. Andererseits muss Ihm klargemacht werden warum es sinnvoll ist das Update zu installieren. Mit Rubygems steht ein gutes System für Ruby auf allen Betriebssystemen bereit (mit Ausnahme von Debian), dass es nicht nur zu einem Kinderspiel macht, sämtliche Bibliotheken zu aktualisieren aber auch Konflikte in verschiedenen Bibliotheken herauszufinden. Natürlich müssen dafür jedoch die entsprechenden Metadaten gepflegt werden, also Abhängigkeiten zu anderen Bibliotheken angeben (~> verwenden!) und die korrekte Ruby Version fixieren (hier sollten direkt Versionen < 1.9 ausgeschlossen werden).
Wiederum die Gefahr bzw. ein Trend, der durch gute Updatemechanismen gefördert wird, ist in meinen Augen der Trend zu Bananensoftware. So wird möglichst schnell ein Produkt auf den Markt gebracht, welches weder gut getestet ist, noch alle Funktionalität enthält. Das bekommt dann den Stempel “Beta Version” aufgedrückt, in dem guten Wissen, die “fertige Version” später einfach und komfortabel per Update nachliefern zu können. Das halte ich aber für den falschen Ansatz. Es führt kein Weg an einer guten Qualitätssicherung vorbei.
Sollten sich also mal wieder ein Benutzer beschweren, dass die Bibliothek nicht mehr mit 1.8 funktioniert, versucht nicht eine Optimierung für diese alte Software durchzuführen, sondern verwendet eure Energie lieber dazu, um zu erklären warum ein Update auf 1.9 wichtiger ist.
Kommentare
Beim Ölwechsel im Auto braucht man sich aber keine Sorgen zu machen, ob die Sitzheizung nachher noch funktioniert, sich alle Türen noch öffnen lassen und das Auto beim Schalten in den dritten Gang evtl. einfach ausgeht. Das neue Öl (sofern man sich an die Anforderungen der Hersteller hält), erfüllt die gleiche Funktion wie das alte: Das Schmieren der Kolben.
Im Gegensatz dazu kommt Ruby 1.9.x mit einer Masse an neuen Funktionen daher, veränderter Syntax etc. Wenn man das einfach austauscht, wird das Programm nachher nicht mehr laufen.
Ruby 1.8 verschmutzt auch nicht durch Verbrennungsrückstände und wird durch Kondenswasser nicht verdünnt. Solange ich meine Gems nicht update, kann meine Ruby 1.8.6-Konfiguration noch im Jahr 2037 zuverlässig funktionieren.
Der Umstieg von 1.8.6 auf 1.9.x ist daher keine Wartung im Sinne eines Ölwechsels sondern eher mit der Neuanschaffung eines PKW zu vergleichen.
Hi Toxicburst,
das hast du ganz richtig gesagt, deine Ruby 1.8.6 Konfiguration hätte genau bis zum Jahr 2037 funktioniert. Aber danach wäre sie z.B. kaputt weil die Datumsfunktion fehlerhaft implementiert war und keine höheren Werte verarbeiten kann. Weiterhin musst du immer damit rechnen, dass neue Sicherheitslücken auftreten, die von niemanden mehr gefixt werden. Oder das Compiler bestimmte Funktionen entfernen und sich der alte Quelltext auf neueren Systemen nicht mehr übersetzten lässt. Und zum Schluss natürlich auch noch das Problem, dass Software ja immer weiterlebt. Die wenigsten Programme haben das Glück über Jahre nicht angefasst zu werden. Es gibt immer wieder kleine Optimierungen oder verbesserte Gems (wieder Sicherheitslücken). Diese werden dann aber mit den alten Ruby Versionen nicht mehr funktionieren.
Wie schon gesagt, jemand der sich mit einer 1.8.6 Konfiguration irgendwo einschließt und damit zufrieden ist, der weiß hoffentlich was er tut. Er sollte aber definitiv nicht die Zukunft blockieren.
Und der Vergleich von Technologie X mit einem Auto hinkt natürlich immer (-; Der Punkt sollte sein, dass man Maintenance betreiben sollte und das schließt das Aktualisieren der Systembasis mit ein.
Zu der Syntax: Im Gegensatz zu vielen anderen Sprachen ist Ruby 1.9 in 99% der Fälle rückwärtskompatibel. Ordentlicher Ruby-Code lässt sich zur Not recht fix backporten.
Der Punkt ist mehr: ich entwickele keine Gems mehr, die ich auf 1.8 teste. jruby –1.9 ist meine aktuelle Baseline. Ich erwarte dahingegen, dass ein ordentlicher Gem 1.9-kompatibel ist.
Auf der einen Seite tut sich verdammt viel in der Software-Technologie und man kommt nicht umhin, auf dem Zug mitzufahren. Das Spannungsfeld wird immer größer, wenn man stehen bleibt, weil man sich immer mehr die Möglichkeiten verbaut, Neuentwicklungen einzusetzen.
Auf der anderen Seite investiert man Zeit, damit eine Software ein Problem löst. Obwohl eine Lösung dann gut funktioniert, muss man regelmäßig das System wieder verändern, nur um mit der Entwicklung mitzugehen. Die so weiterentwickelte Software löst das Problem immer noch genauso, wie vorher, und doch muss ich immer wieder Zeit reinstecken.
Zeit = Kraftaufwand = Ressourcenbindung = Geld = weniger Freizeit ;-)
Gibts eine Lösung aus dem Dilemma? Mir fällt keine ein, aber manchmal wünsche ich mir etwas weniger Entwicklungstempo. Aber im nächsten Moment ärgere ich mich wieder über ein fehlendes Feature, was hätte längst schon entwickelt werden können…
Autos: Die sind in ihrer Entwicklung schon deutlich weiter fortgeschritten und wesentliche Dinge ändern sich lange nicht so schnell, wie in der Computerbranche.