Dieser Artikel erschien ursprünglich in meinem ersten Weblog das Netzbuch, das von Mai 2002 bis November 2006 aktiv war, und wurde hier aus blognostalgischen Gründen archiviert. Aktuellere Artikel hat der Uninformat im Angebot.

Rails und Updates

Webworking

StammleserInnen werden sich erinnern: Rails-Updates verhalfen meinem Haarschopf zu einem höheren Grauanteil.

Nun kam das Update auf Rails 1.1, und auf Shared-Hosting-Umgebungen klappten einige Rails-Applikationen zusammen wie Kartenhäuser im Durchzug, ohne dass sich die Nutzer dagegen wehren konnten (Shared-Hosting eben). Jetzt hat der Meister DHH persönlich die Lösung verkündet: Jede Rails-Applikation wird Rails mit der Applikation ausliefern. Was zu heftigen Debatten ebendort führte.

Die Idee ist unkonventionell, aber sinnvoll. Aber letztendlich eine späte Bestätigung meiner damaligen Aussage bezüglich Updates. Und der Produktiv-Host bleibt vorerst auf Rails 1.0. Ihr wisst schon, die Haare. ;-)



4 Kommentare



hugo am 02.04.2006:


Zur Ehrenrettung von Rails: das ist mit anderen Frameworks nicht besser. Ich mache das bei Django schon lange so, das jedes Projekt einen eigenen Django-Checkout meines lokalen Django-Tree bekommt, damit ich genau die Kontrolle über die eingesetzte Version habe. Sonst landet man früher oder später im Irrenhaus …

Ralf G. am 02.04.2006:

Ich sehe das auch nicht so tragisch, ich bin da mehr pragmatisch orientiert. Mir gefällt aber die Erkenntnis, dass Probleme beim Update doch nicht nur am viel zu doofen Admin liegen. ;-)

Nilsemann am 05.04.2006:

Das ist der Grund warum man ein Update erst 2 Wochen nach dem Erscheinen aufspielen sollte. Aber wir sind ja wie kleine Kinder und können es nicht abwarten.

Ralf G. am 05.04.2006:

Wir nicht. Die “Großen” wie Dreamhost und Textdrive sind so. ;-)

rails ror rubyonrails