Laravel ใช้ semantic versioning
หน้า Release Notes ของ Laravel บอกว่า Laravel และ package ของทีม Laravel ใช้ Semantic Versioning เลขอย่าง 13.38.0 แยกเป็นสามส่วน
- Major (13) ออกปีละครั้งช่วงไตรมาสแรกของปี เป็นรุ่นเดียวที่มี breaking change ได้
- Minor (38) ออกได้บ่อยถึงทุกสัปดาห์ มีฟีเจอร์ใหม่ แต่ต้องไม่ทำให้โค้ดเดิมพัง อย่าง Laravel 13.38 ที่เพิ่ม middleware กันอ่านข้อมูลเก่าจาก read replica
- Patch (0) แก้บั๊กอย่างเดียว
ใน composer.json เราจึงเขียน version constraint แบบ ^13.0 สั่ง composer update ทีไรก็ได้ minor กับ patch ล่าสุดของ 13 มาทุกครั้ง แต่ไม่ข้ามไป 14 เอง
"require": {
"php": "^8.3",
"laravel/framework": "^13.0"
}
ข้อยกเว้นที่ควรรู้คือ named arguments Laravel ไม่นับชื่อพารามิเตอร์เป็นส่วนของ backward compatibility และอาจเปลี่ยนชื่อได้ใน minor ไหนก็ได้ เรียกเมธอดของ Laravel ด้วยชื่อพารามิเตอร์จึงเสี่ยงพังตอนอัปเดต
// ถ้าวันหนึ่ง Laravel เปลี่ยนชื่อพารามิเตอร์ $limit บรรทัดนี้จะพัง
Str::limit($text, limit: 50);
// เรียกตามลำดับแบบเดิมปลอดภัยกว่า
Str::limit($text, 50);
แต่ละเวอร์ชันแก้บั๊ก 18 เดือน และแก้ช่องโหว่ 2 ปี
นโยบายตอนนี้ใช้เหมือนกันทุกเวอร์ชัน นับจากวันออก
- 18 เดือนแรก แก้ทั้งบั๊กและช่องโหว่
- อีก 6 เดือนถัดมา แก้เฉพาะช่องโหว่
- ครบ 2 ปี ก็หมดอายุ ไม่มีแพตช์อะไรอีก
สถานะ ณ วันที่ 26 ต.ค. 2569 จากตาราง Support Policy
| Laravel | PHP ที่รองรับ | ออกเมื่อ | แก้บั๊กถึง | แก้ช่องโหว่ถึง | ตอนนี้ |
|---|---|---|---|---|---|
| 10 | 8.1 ถึง 8.3 | 14 ก.พ. 2566 | 6 ส.ค. 2567 | 4 ก.พ. 2568 | หมดอายุแล้ว |
| 11 | 8.2 ถึง 8.4 | 12 มี.ค. 2567 | 3 ก.ย. 2568 | 12 มี.ค. 2569 | หมดอายุแล้ว |
| 12 | 8.2 ถึง 8.5 | 24 ก.พ. 2568 | 13 ส.ค. 2569 | 24 ก.พ. 2570 | แก้เฉพาะช่องโหว่ |
| 13 | 8.3 ถึง 8.5 | 17 มี.ค. 2569 | ไตรมาส 3 ปี 2570 | 17 มี.ค. 2571 | support เต็ม |
วันที่ในตารางไม่ได้นับครบ 18 เดือนหรือ 2 ปีเป๊ะทุกตัว ทีม Laravel ขยับได้ อย่างวันแก้บั๊กของ Laravel 13 ยังเขียนไว้แค่ไตรมาส 3 ปี 2570 ดูวันที่จริงจากตารางในหน้า Release Notes จะตรงที่สุด
พอ major ใหม่ออกราวต้นปี major ก่อนหน้าจะเหลือเวลาแก้บั๊กอีกไม่กี่เดือน และแก้ช่องโหว่อีกราวหนึ่งปี ช่วงนั้นคือเวลาที่เราควรอัปเกรด อย่างตอนนี้ Laravel 12 เลยช่วงแก้บั๊กมาแล้ว และจะหมดอายุ 24 ก.พ. 2570 ซึ่งน่าจะใกล้กับช่วงที่ Laravel 14 ออกพอดี
ไม่มี LTS แล้วตั้งแต่ Laravel 6
Laravel เคยมีเวอร์ชัน LTS (Long Term Support) ตามนโยบายสมัย Laravel 6 major ออกทุกหกเดือน (กุมภาพันธ์กับสิงหาคม) เวอร์ชันทั่วไปแก้บั๊ก 6 เดือนและแก้ช่องโหว่ 1 ปี ส่วนเวอร์ชัน LTS อย่าง 5.5 กับ 6 แก้บั๊ก 2 ปีและแก้ช่องโหว่ 3 ปี
ตั้งแต่ Laravel 8 Laravel เปลี่ยนมาออก major ปีละครั้ง และให้ทุกเวอร์ชันได้ support เท่ากันที่ 18 เดือนกับ 2 ปี เหตุผลที่ทีม Laravel ให้ไว้คือลดภาระคนดูแล และเปลี่ยนวิธีออกฟีเจอร์ ฟีเจอร์ใหม่ส่วนใหญ่ออกใน minor ระหว่างปีโดยไม่มี breaking change ส่วน major กลายเป็นรอบที่อัปเดต dependency อย่าง Symfony เป็นหลัก
ผลที่เห็นได้ชัดคืออัปเกรด major ไม่หนักเหมือนสมัย Laravel 5 Release Notes ของ Laravel 13 บอกว่าแอปส่วนใหญ่ขึ้นจาก 12 ไป 13 ได้โดยแก้โค้ดไม่มาก และทีม Laravel ตั้งเป้าว่าอัปเกรด major แต่ละรอบควรเสร็จได้ในวันเดียว
ถ้าใครยังอยู่บน Laravel 6 เพราะเคยได้ยินว่าเป็น LTS เวอร์ชันนั้นหมดอายุไปตั้งแต่เดือนกันยายน 2565 แล้ว
package อื่นของทีม Laravel แก้บั๊กให้แค่ major ล่าสุด
นโยบาย 18 เดือนกับ 2 ปีใช้กับตัว framework (laravel/framework) ส่วน package อื่นของทีม Laravel อย่าง Horizon, Sanctum, Cashier หรือ Scout ได้แก้บั๊กเฉพาะ major ล่าสุดเท่านั้น
ถ้าเราล็อก Horizon ไว้ที่ major เก่าเพราะยังไม่อยากแก้ config ก็จะไม่ได้บั๊กที่แก้หลังจากนั้นเลย ตอนอัปเกรด framework จึงควรไล่ดู package ของทีม Laravel ไปพร้อมกันด้วย
ดูคู่กับรอบ support ของ PHP
Laravel แต่ละเวอร์ชันรองรับ PHP เป็นช่วง และ PHP เองก็มีรอบ support ของตัวเอง สองรอบนี้ไม่ได้จบพร้อมกัน
อย่าง Laravel 13 ต้องใช้ PHP 8.3 ขึ้นไป แต่ PHP 8.3 จะได้แพตช์ความปลอดภัยถึง 31 ธ.ค. 2570 ขณะที่ Laravel 13 อยู่ถึง 17 มี.ค. 2571 เว็บที่เป็น Laravel 13 บน PHP 8.3 จึงต้องย้าย PHP ก่อน Laravel จะหมดอายุ ถ้าจะตั้งเซิร์ฟเวอร์ใหม่ตอนนี้ ใช้ PHP 8.4 หรือ 8.5 ไปเลยจะอยู่ได้ยาวกว่า
นอกจาก PHP แล้ว Laravel ยังกำหนดเวอร์ชันฐานข้อมูลที่รองรับไว้ด้วย เซิร์ฟเวอร์ที่ใช้ MySQL หรือ PostgreSQL รุ่นเก่ามาก ๆ ควรเช็คหน้านี้ก่อนอัปเกรด
กรณีที่อาจเจอตอนวางแผนอัปเกรด
- ระบบที่ยังเป็น Laravel 8, 9 หรือ 10 หมดอายุไปหมดแล้ว อัปเกรดทีละ major ตาม upgrade guide ของแต่ละเวอร์ชันจะคุมง่ายกว่ากระโดดทีเดียว ส่วนงานแก้โค้ดซ้ำ ๆ ให้ Rector ช่วยได้ ถ้ามีงบ บริการอย่าง Laravel Shift ก็ทำ pull request อัปเกรดให้ทีละ major
composer updateแล้วไม่ขึ้น major ใหม่ เป็นเรื่องปกติ เพราะ^12.0ไม่ข้ามไป 13 ต้องแก้ constraint ในcomposer.jsonเองตอนอัปเกรด- อยากรู้ว่า package ที่ลงอยู่มีช่องโหว่ไหม
composer auditเช็คcomposer.lockกับฐานข้อมูล security advisory ให้ ส่วน Dependabot เปิด pull request อัปเดต package ให้เองเมื่อมีเวอร์ชันใหม่ - ระบบที่ยังเป็น Laravel 12 ตอนนี้ได้แค่แพตช์ความปลอดภัย บั๊กที่ทีม Laravel แก้ใน 13 จะไม่ย้อนมาที่ 12 วางแผนขึ้น 13 ก่อนเดือนกุมภาพันธ์ 2570 ได้เลย






