Rails 7.1 เปิดตัวแล้ว

 (github.com/rails)
2 คะแนน โดย GN⁺ 2023-10-08 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เมื่อใช้ config.load_defaults 7.1 การ serialization เริ่มต้นของ ActiveSupport::MessageVerifier และ ActiveSupport::MessageEncryptor จะเปลี่ยนจาก Marshal เป็น ActiveSupport::JSON และยังคงอ่านข้อความ Marshal เดิมได้
  • ActiveRecord::Base.serialize เปลี่ยนให้ไม่ใช้ YAML เป็นค่าเริ่มต้น และสามารถกู้คืนค่าเริ่มต้นเดิมได้ด้วย config.active_record.default_column_serializer = YAML
  • เพิ่ม รูปแบบแคช ใหม่ 7.1 ซึ่งใช้เป็นค่าเริ่มต้นสำหรับแอปใหม่ และแอปเดิมสามารถเปิดใช้ได้ด้วย config.load_defaults 7.1 หรือ config.active_support.cache_format_version = 7.1
    • รายการที่บันทึกด้วยรูปแบบแคช 6.1 หรือ 7.0 สามารถอ่านได้ในรูปแบบ 7.1
    • สำหรับการ rolling deploy ของ Rails 7.1 ควรรักษารูปแบบแคชไว้ในการ deploy ครั้งแรก แล้วค่อยเปิดใช้รูปแบบแคช 7.1 ในการ deploy ครั้งถัดไป
  • เพิ่ม serialization แบบ :message_pack และ :message_pack_allow_marshal ให้กับ MessageEncryptor, MessageVerifier และ config.active_support.message_serializer โดยต้องใช้ gem msgpack >= 1.7.0
  • ป้องกัน การเปิดเผยค่าลับ ใน inspect ของ ActiveSupport::KeyGenerator, MessageEncryptor, EncryptedConfiguration และอ็อบเจ็กต์เข้ารหัสของ Active Record พร้อมเสริมการป้องกัน XSS ใน ActionView::Helpers และ ERB::Util
  • เพิ่มการตรวจสอบ password_challenge และเมธอด #{attribute}_salt ให้กับ has_secure_password และเพิ่ม authenticate_by เพื่อลดการโจมตีแบบ enumerating ด้วย timing ตามการมีอยู่ของบัญชี
  • ขยายการรองรับใน Active Record สำหรับ composite primary key และ composite foreign key รวมถึงรองรับไวยากรณ์ tuple ใน where, การเรียงลำดับ batch ด้วย composite key และการอนุมาน composite primary key จาก schema
  • เพิ่มการรองรับ PostgreSQL สำหรับคำสั่ง migration เพื่อเปลี่ยนชื่อ enum, เพิ่มค่า, เปลี่ยนค่า รวมถึง exclusion constraint, unique constraint, ตัวเลือกดัชนี INCLUDE และการรองรับดัชนี NULLS [NOT] DISTINCT
  • อะแดปเตอร์ SQLite3 ระบุว่าประสิทธิภาพเฉลี่ยดีขึ้น 2× ด้วยการตั้งค่า Write-Ahead-Log normal syncing mode, capped journal size, shared memory buffer และ shared cache พร้อมเปิดใช้ strict strings mode เป็นค่าเริ่มต้นเพื่อปิดใช้งาน double-quoted string literal
  • การวนซ้ำแบบ batch ทั้งตารางของ Active Record ใช้ range iteration เป็นค่าเริ่มต้นเพื่อปรับปรุงประสิทธิภาพ โดยมีผลการทดสอบกับ 10 ล้านเรคคอร์ดบน PostgreSQL: querying 253s→30s, updating 288s→124s, deleting 268s→83s
  • เปิดใช้ connection pooling เป็นค่าเริ่มต้นสำหรับ MemCacheStore และ RedisCacheStore หากต้องการปิดใช้งานต้องระบุ pool: false ในการตั้งค่า cache store
  • เพิ่มอะแดปเตอร์สำหรับไคลเอนต์ฐานข้อมูล Trilogy ทำให้ใช้ adapter: trilogy หรือ DATABASE_URL ในรูปแบบ trilogy:// ได้
  • รูปแบบแท็กเริ่มต้นของ ActiveRecord::QueryLogs เปลี่ยนเป็นรูปแบบ SQLCommenter และสามารถใช้รูปแบบเดิมได้ด้วย config.active_record.query_log_tags_format = :legacy
  • รายการที่เลิกสนับสนุนและถูกลบประกอบด้วยการใช้ singleton ของ ActiveSupport::Deprecation, SafeBuffer#clone_empty, อาร์กิวเมนต์ rewhere ของ #merge, deferrable: true ของ add_foreign_key, TestFixtures#fixture_path รวมถึงการจัดระเบียบการตั้งค่าและ API ของ Active Record หลายรายการที่ deprecated แล้ว
  • เพิ่ม ActionView::TestCase.register_parser ในการทดสอบ Action View เพื่อให้ลงทะเบียน parser สำหรับผลลัพธ์การ render ได้ โดยมี parser เริ่มต้นเป็น :html และ :json

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2023-10-08
ความคิดเห็นจาก Hacker News

  • Rails นั้นยอดเยี่ยม และตอนนี้ดีกว่าที่เคยเป็นมา
    ช่วงต้นอาชีพผมใช้ Django กับ Laravel เป็นหลัก จากนั้นย้ายไปทำงานฟรอนต์เอนด์แบบที่พบได้ทั่วไปในยุคนี้ และปีนี้ก็กลับมารับโปรเจกต์ Rails + Hotwire อีกครั้ง
    ผมประหลาดใจจริง ๆ ว่ามันเรียบง่ายขึ้นแค่ไหน และเสียดายที่คนส่วนใหญ่ลืมไปแล้วว่ามันสามารถง่ายได้ขนาดนี้ น่ากลัวด้วยที่คนที่เข้ามาในวงการตอนนี้อาจไม่ได้สัมผัสความเรียบง่ายแบบนี้เลย
    ถ้าคุณยังไม่เคยลอง Rails หรือเลิกสนใจไปเพราะได้ยินแต่คำพูดอย่าง “PHP หน้าตาน่าเกลียด / Rails ตายแล้ว / JavaScript เละเทะ” ผมแนะนำให้ลองเมินคำพูดคนอื่นสักพัก แล้วเปิดใจลองใช้ดู
    มันอาจไม่ใช่ตัวเลือกที่ดีที่สุดสำหรับสภาพแวดล้อมที่มีวิศวกร 1,000 คนทำงานใน repository เดียวกัน แต่สำหรับ ทีมขนาดเล็ก แล้วแทบไม่มีคู่แข่ง และนำหน้าตัวเลือกอื่นไปไกลมาก พูดตรง ๆ Laravel เองก็อาจดีพอ ๆ กันได้

    • ผมอยากใส่ Phoenix LiveView เข้ามาด้วย
      ในแง่ความเร็วของการพัฒนาช่วงแรก ผมมองว่า Rails ชนะเสมอ convention ของมันแน่นและออกแบบมาดีมาก จนแทบไม่มีอะไรตามทันได้ใกล้เคียง Laravel กำลังไล่ตามอยู่ก็จริง แต่ผมว่ายังไม่ถึงขั้นนั้น
      แต่ LiveView ขยายสเกลได้ดีกว่าในทุกความหมาย มีของที่ให้มาพร้อมใช้งานเยอะ ทั้ง authentication, การเข้าถึงฐานข้อมูล, job queue, mailer, เครื่องมือทดสอบครบชุด ฯลฯ แทบไม่ต้องเขียน JavaScript เอง และยังมี BEAM ซึ่งเป็น virtual machine ที่ยอดเยี่ยมด้วย
      อย่างน้อยก็ดีที่โปรเจกต์พวกนี้ทั้งหมดช่วยสู้ในแนวทาง “ถอยกลับมาหนึ่งก้าว” ที่ทำงานผมใช้ React กับ Relay และแม้จะใช้ JavaScript ฝั่งฟรอนต์เอนด์มานานและคิดว่าตัวเองทำได้พอสมควร ก็ยังมีอุปสรรคให้ข้ามมากเกินไปจนเหนื่อย
    • เมื่อเทียบกับ Django แล้ว น่าสนใจที่อย่างน้อยตอนนี้คุณไม่ได้มองว่าสองตัวนี้อยู่ระดับเดียวกัน ผมอยากรู้ว่ามี เหตุผลเฉพาะเจาะจงอะไรที่ชอบ Rails มากกว่า Django หรือเปล่า
    • ผมชอบ Rails แต่ในประเทศของผมแทบไม่มีใครใช้เลย และบริษัทที่ใช้ก็มักมองหานักพัฒนาระดับพ่อมดแทบทั้งนั้น
      พอหางานไม่ได้ก็เลยสะสมประสบการณ์ได้ไม่พอ และสุดท้ายก็แพ้พ่อมดพวกนั้น บางประกาศรับสมัครเปิดค้างไว้นานเกิน 12 เดือนด้วยซ้ำ
      แทนที่จะเป็นแบบนั้น ผมเลยกำลังแพร่ JavaScript ให้โลกมากขึ้น เพราะมันเป็นที่ที่มีดีมานด์
    • นักพัฒนา Rails หลายคนที่ผมรู้จักย้ายไปใช้ ember.js กัน เพราะ ember.js ก็เป็นเฟรมเวิร์กที่ขับเคลื่อนด้วย convention ไม่ใช่แนวที่ปลั๊กอินจาก third party จำนวนมากพังอยู่เรื่อย ๆ
      ในเชิงโครงสร้าง ผมชอบแนวทางของ ember-data มีหลายส่วนที่ทำ automation ได้ในงานอย่าง left join/right join ของ dataset และยังมี mock server แบบบูรณาการด้วย
      แต่คงเพราะมันทำงานได้ดีเกินไป เลยดูไม่เท่เท่าสิ่งอื่น ๆ
      https://emberjs.com/

  • ผมอัปเกรด แอป Rails 7.0 ขนาด 13,000 บรรทัด ไปเป็น 7.1 แล้ว นอกจากความแตกต่างระหว่าง 7.0 กับ 7.1[0] ก็เปลี่ยนโค้ดตั้งค่า test แค่ 1 บรรทัด แล้วทุกอย่างก็ทำงานได้
    ในแง่เส้นทางอัปเกรดที่ง่าย ผมถือว่าประสบความสำเร็จ ตอนนี้ส่วนที่สนุกคือการ refactor โค้ดบางส่วนให้ใช้ฟีเจอร์ใหม่ของ 7.1
    ถ้าสนใจ ผมอัปเดตแอปตัวอย่าง Rails / Docker เป็น 7.1 ไว้แล้วเช่นกัน https://github.com/nickjj/docker-rails-example
    Rails 7.1 มี Dockerfile มาให้ก็จริง แต่ยังมีตัวเลือกให้เติมได้อีกมาก เช่น ใช้ Docker Compose เพื่อสร้างประสบการณ์ที่ใช้งานได้ทันทีทั้งใน development และ production และรวม Postgres, Redis, Action Cable, Sidekiq ฯลฯ เข้าไปด้วย
    [0]: https://railsdiff.org/7.0.8/7.1.0

  • กำลังพยายามย้าย โค้ดเบส Rails 6 ที่ค่อนข้างใหญ่และมี React ติดอยู่เต็มไปหมด ไปสู่แนวทางแบบ “ไม่ใช้” JavaScript แบบใหม่ที่ใช้ Hotwire ขอให้โชคดีนะ
    Rails นั้นยอดเยี่ยมเมื่อคุณยึดตามค่าเริ่มต้น แต่ทันทีที่ออกนอกค่าเริ่มต้นเหล่านั้น ก็จะกลายเป็นดินแดนแห่งความเจ็บปวด

    • ตอนนี้ทำงานกับโค้ดเบส Rails 7 ที่ค่อนข้างใหม่ ตอนแรกเริ่มใช้ Stimulus แต่กำลังพิจารณาย้ายไป React ด้วยเหตุผลหลายอย่าง
      ถ้าจะจ้างวิศวกรฟรอนต์เอนด์ กลุ่มผู้สมัครที่เป็น React มีขนาดใหญ่กว่าหลายหลัก การหาแพ็กเกจ vanilla JavaScript สำหรับงานทั่วไปแล้วเอามาห่อด้วย Stimulus controller ก็ยากขึ้นเรื่อย ๆ เมื่อเทียบกับการหาแพ็กเกจ React
      Stimulus ก็ไม่ได้มีวิธีที่ชัดเจนสำหรับเขียน unit test ให้ controller ด้วย ใน React ใช้ jest และ react-test-renderer ได้ตามปกติ
      นอกจากนี้ประเด็นถกเถียงล่าสุดเรื่อง Turbo TypeScript ก็ไม่ได้ทำให้เชื่อมั่นในการดูแลระบบนิเวศ Hotwire ระยะยาว
      ยังไม่ได้ตัดสินใจแน่ชัด ข้อดีที่ชัดเจนคือ Stimulus ให้ความรู้สึกว่าเป็นวิธีเขียนโค้ดฟรอนต์เอนด์ที่เป็นแบบ Rails มาก ๆ โดยเฉพาะสำหรับทีมเล็กที่คุ้นเคยกับ Rails อยู่แล้ว
    • คำว่า “Rails ดีถ้ายึดตามค่าเริ่มต้น และเจ็บปวดถ้าออกนอกกรอบ” ใช้ได้กับ ทุกเฟรมเวิร์ก
      ถ้าแอปพลิเคชันค่อนข้างเรียบง่ายและเข้ากับแนวทางของเฟรมเวิร์กได้ดี เฟรมเวิร์กก็ยอดเยี่ยม แต่ถ้าต้องการโครงสร้างที่ซับซ้อนและยืดหยุ่นมากขึ้น ก็ควรไปดูไลบรารี
    • หมดศรัทธากับ การผสาน JavaScript ของ Rails แล้ว
      ตอนนี้ก็ทำ server-side rendering ด้วย slim หรือไม่ก็ทำเป็น API-only แล้วแยกฟรอนต์เอนด์ออกไป
      Rails เปลี่ยนทิศทางในการทำ JavaScript มาหลายครั้งเกินไป ทั้ง CoffeeScript, asset precompile, webpack ฯลฯ
    • ไม่อยากแนะนำให้ย้ายฟรอนต์เอนด์ React เดิมไป Hotwire พร้อมกับอัปเกรด Rails เอง คิดว่าควรอัปเกรด Rails ไปถึง 7.1 แบบแยกต่างหากก่อน
      อีกอย่าง วิธีจัดการ JavaScript ของ single-page app ใน Rails 7+ ก็สมเหตุสมผลกว่าเดิมมาก โดยพื้นฐานแล้วใช้เครื่องมือ build ที่ต้องการแยกจากแอป Rails ได้เลย
      ระหว่างพัฒนา อาจต้องรันอะไรอย่าง yarn build --watch ควบคู่กับ rails s แต่โดยส่วนตัวคิดว่าไม่แย่ และทำให้เรียบง่ายขึ้นมาก
      บริษัทของเราทำซอฟต์แวร์ที่ทำให้อัปเกรด Rails ได้อัตโนมัติ และยังมีบริการเต็มรูปแบบที่ช่วยอัปเกรด Rails ให้ด้วย ถ้าสนใจ ติดต่อ steve (at) infield.ai หรือสร้างแผนอัปเกรด Rails ฟรีได้ที่ https://app.infield.ai/users/sign_up ไม่ต้องใช้บัตรเครดิต
      ดูรายละเอียดเพิ่มเติมได้ที่ https://docs.infield.ai/docs/creating-an-upgrade-path
    • แนะนำให้ลองใช้ https://vite-ruby.netlify.app/guide/rails.html
      ในกรณีของผม มันเข้ากันได้แทบจะทันทีเหมือนเป็น ตัวแทน webpack

  • ชอบ Rails และใช้มาเป็นครั้งคราวตั้งแต่สมัย Rails 2
    เป็นเฟรมเวิร์กที่ดีมาก และสำหรับคนอย่างผมที่ต้องเปิดเว็บขึ้นมาเป็นครั้งคราว มันคือ เส้นทางที่แรงต้านน้อยที่สุด จริง ๆ
    แต่ขั้นตอนการตั้งค่าให้ Rails รันบนโน้ตบุ๊กเครื่องใหม่นั้นทรมาน ต้องมี node แล้วก็ต้องมี npm ด้วย ในฐานะนักพัฒนาแบ็กเอนด์ ผมไม่ค่อยรู้ว่าควรตั้งค่า node อย่างไร หรือควรทำตามลำดับไหน
    ไม่ได้ทำบ่อย เลยรู้สึกเหมือนต้องสู้กันทุกครั้ง สุดท้ายก็ทำได้ แต่ก็ไม่เคยแน่ใจว่าทำไมทุกอย่างถึงเข้าที่เข้าทางในที่สุด
    อยากให้มีตัวติดตั้งที่จัดการของที่จำเป็นทั้งหมดให้พร้อมกัน แล้วทำให้ rails ใช้งานได้เลย ตัวติดตั้ง rvm ตั้งค่า rails บน ruby ให้ แต่ไม่ได้ตั้งค่าระบบ node ที่อยู่ข้างใต้ให้

    • มีตัวจัดการเวอร์ชันชื่อ asdf ที่เหมาะกับการจัดการ nodejs ส่วน Ruby ไม่เคยลอง
      https://asdf-vm.com/
    • เข้าใจคำว่า “เป็นนักพัฒนาแบ็กเอนด์เลยไม่รู้การตั้งค่า node”
      Node เป็นที่รู้จักหลัก ๆ ในฐานะเครื่องมือฟรอนต์เอนด์ และ Rails ก็ใช้เพื่อจุดประสงค์นั้น แต่เท่าที่จำได้ อย่างน้อยในตอนแรก Node ถูกสร้างมาเพื่อนำ JavaScript runtime ไปใช้ฝั่งแบ็กเอนด์
      ถ้าไม่ใช้ package manager บน Windows ก็น่าจะเป็นแค่ node.exe และเท่าที่รู้คือดาวน์โหลด npm มาแตกไฟล์ แล้วใส่ node กับ npm ลงในตัวแปรสภาพแวดล้อม PATH ก็พอ
    • แนวคิดหลักทั้งหมดของ Rails 7 คือ การกำจัด dependency บน node
    • ไม่เคยใช้ Rails เลยเลยสงสัยว่า “Ruby on Rails” ทำไมถึงต้องใช้ nodejs
      แล้วการติดตั้ง node ก็ค่อนข้างง่าย จริง ๆ ง่ายเกินไปด้วยซ้ำ อยากให้มันยากกว่านี้มาก ๆ และต้องมีปริญญาถึงจะทำได้
    • คอมมูนิตี้ Ruby/Rails เป็นหนึ่งในคอมมูนิตี้ที่ดีที่สุดและเป็นมิตรที่สุดเท่าที่เคยเห็นมา แต่สิ่งที่แย่ที่สุดในนั้นคือ ความเกลียด JavaScript อย่างไม่ต้องสงสัย
      JavaScript ก็เป็นแค่เครื่องมือเหมือนอย่างอื่น ๆ ไม่ว่าจะชอบหรือไม่ มันเป็นเครื่องมือที่สำคัญมาก และไม่ว่าจะชอบหรือไม่ มันจะยังอยู่ไปอีกนาน
      ถ้าเปิดใจสักหน่อยและเรียนรู้อย่างน้อยพื้นฐาน งานต่าง ๆ จะง่ายขึ้น

  • หวังว่า Rails + HTMX และแนวทางที่โรย JavaScript เพียงเล็กน้อยเฉพาะบนหน้าที่มีการโต้ตอบสูงมาก ๆ จะกลับมารุ่งอีกครั้ง
    การใช้ Rails ร่วมกับ Slim/HAML สนุกมาก ถ้าต้องการก็ใช้ไลบรารีอย่าง ViewComponents เพื่อทำให้ partial rendering ง่ายขึ้นได้ด้วย เติม web components เข้าไปก็สร้างหน้าที่ค่อนข้างโต้ตอบได้มาก และถ้าบางหน้าจำเป็นจริง ๆ ก็ใช้ React ได้
    HATEOAS ช่วยลดความซับซ้อนของแอปพลิเคชันได้มาก ถึงอย่างนั้นถ้าต้องการ API การตอบกลับตาม MIME type ที่ต่างกันก็ทำได้ง่ายมาก และถ้าต้องการก็แชร์ endpoint เดียวกันได้ด้วย
    จากประสบการณ์ แอปพลิเคชันส่วนใหญ่ที่ใช้ React จริง ๆ แล้วไม่จำเป็นต้องใช้ React เลย ใช้ React เพียงเพราะมี popup menu ไม่กี่อัน
    ดังนั้นถ้าเริ่มมีแอปขนาดใหญ่ที่ไม่ใช้ React หรือใช้ React เพียงนิดเดียวออกมา ก็หวังว่าจะมีคนตระหนักว่าแอปพลิเคชันของเราทุกวันนี้ซับซ้อนเกินจำเป็นแค่ไหน
    แต่ก็เห็นคนพูดกันแล้วว่า “ทุกคนใช้ React กันหมด ดังนั้นเราต้องเปลี่ยนไปใช้ React” ถอนหายใจเลย
    ฝันไปก่อนได้แหละ

  • ประกาศอย่างเป็นทางการอยู่ที่นี่: https://rubyonrails.org/2023/10/5/Rails-7-1-0-has-been-released
    มีรายละเอียดระดับสูงเพิ่มอีกเล็กน้อย และตั้งตารอที่จะได้ลองใช้การเปลี่ยนแปลงใหม่บางอย่าง โดยเฉพาะ เมธอดคิวรีแบบอะซิงโครนัส ใหม่ น่าจะมีประโยชน์มากสำหรับการปรับปรุงประสิทธิภาพอย่างรวดเร็ว

  • Rails ในฝั่งแบ็กเอนด์ยังไม่ได้รับการประเมินคุณค่าอย่างเพียงพอ
    แต่ฝั่งฟรอนต์เอนด์นั้นยุ่งเหยิงมานานมากจริง ๆ

    • ไม่ได้คัดค้านว่า “ฝั่งฟรอนต์เอนด์ยุ่งเหยิงมานาน” แต่ตัวฟรอนต์เอนด์เองก็ยุ่งเหยิงมานานเช่นกัน
      ตอนนี้การทำงานด้วยชุด Rails 7.1 + Hotwired + Importmaps เป็นเรื่องสนุก
      แต่ก็ต้องรอจนกว่าเบราว์เซอร์จะรองรับอย่างน้อย ES6 และ Import Maps ได้ดีขึ้น
      ดูจากวันที่ของบทความนี้ https://web.dev/import-maps-in-all-modern-browsers/ มีการประกาศเมื่อ 28 มีนาคม 2023 ว่าสามารถใช้ importmaps ได้ในเบราว์เซอร์สมัยใหม่ทั้งหมด
      ดังนั้นจนถึงตอนนี้จึงไม่มีทางเลี่ยง Webpack, Yarn และเครื่องมือช่วย JavaScript อื่น ๆ ได้
      ตอนนี้มี importmaps แล้ว และการรองรับ ES6 ของเบราว์เซอร์ก็ดีพอ https://caniuse.com/?search=es6 ทำให้สามารถใช้ JavaScript สมัยใหม่ได้โดยแทบไม่ต้องมีเครื่องมือเพิ่มเติม
    • เห็นด้วย แล้วทางเลือกตรงนี้มีอะไรบ้าง? Rails ใน โหมด API-only หรือ?
    • ชอบฟีเจอร์ใหม่ของ Hotwire นะ สงสัยว่าฝั่งฟรอนต์เอนด์มีอะไรที่ไม่ถูกใจ

  • เมื่อไม่กี่สัปดาห์ก่อน เพื่อนพูดติดตลกว่า “ถ้ามีการประกาศรีลีส Rails แล้วคุณยังไม่ได้เปิด PR อัปเกรด มันเกิดขึ้นจริงหรือเปล่า?”
    เอาละ ตอนนี้ถึงเวลาเปิด PR แล้ว แม้ว่าจะต้องไปต่อคิวหลัง PR 7.0 ที่ค้างมาหลายเดือนก็ตาม

  • จากประสบการณ์ หลายทีมมีปัญหาในการสร้าง codebase ที่สะอาดด้วย ActiveRecord

  • อย่าด่ากันนะ แต่ยังใช้ Rails 4.2 อยู่และก็พอใจ
    มันให้ทุกอย่างที่จำเป็นสำหรับงาน SaaS แบ็กเอนด์ที่ไม่มีหรือมี JavaScript น้อย ซึ่งผมทำเองหรือทำให้บริษัท B2B และยังรันบน VPS สเปกต่ำได้ด้วย
    ถ้ามีเวลาตอบ ก็อยากรู้ว่าทำไมถึงควรอัปเกรด

    • ผมก็ใช้เวอร์ชันเก่าเหมือนกัน ก่อนอื่นควรตรวจสอบว่าสามารถอัปไปถึงแพตช์/ไมเนอร์เวอร์ชันล่าสุดได้หรือไม่
      ปัญหาหลักของเวอร์ชันเก่าคือช่องโหว่ใน gem ที่เชื่อมโยงอยู่ เช่น nokogiri อาจอัปเกรดไม่ได้หากไม่อัปเกรดเมเจอร์ของ Rails
      แต่แอปส่วนใหญ่ไม่ได้ทำอย่างเช่นการพาร์ส XML ที่ซับซ้อน ดังนั้นช่องโหว่จำนวนมากจึงอาจไม่เกี่ยวข้อง จึงต้องมีงานบำรุงรักษาเล็กน้อยเพื่อตรวจสอบว่ายังปลอดภัยอยู่ บ่อยครั้งก็มีการใส่ monkey patch เพื่อป้องกันบั๊ก
      การอัปเกรดจะทำให้ความปลอดภัยดีขึ้นและลดเวลาบำรุงรักษา แต่ก็ต้องคำนึงถึงต้นทุนของการอัปเกรดอย่างต่อเนื่องด้วย อีกปัจจัยหนึ่งคือเวอร์ชันใหม่จะรองรับ Ruby ที่เร็วกว่าได้
      ปกติเวลาสร้างแอป Rails จะใช้รีลีสล่าสุด แต่หลังจากนั้นจะไม่อัปเวอร์ชัน Rails เว้นแต่ว่ามันเป็นที่นิยมมาก หรือแอปเก่ามากจนมีบางอย่างไม่ทำงานบนระบบใหม่
    • ควรอัปเกรดเพราะเรื่อง ความปลอดภัย