Quarkus 3.40 LTS ดูแล 12 เดือน ทีมงานควรเลือกทางไหนก่อนรุ่นใหม่

Quarkus ประกาศรุ่นดูแลระยะยาวใหม่ โดยระบุว่าจะสนับสนุน 12 เดือน แปลว่าทีมมีกรอบเวลาหนึ่งปีสำหรับวางแผนดูแลรุ่นนี้ (ประกาศ Quarkus) รุ่นที่เปิดตัววันที่ 30 กันยายน 2026 คือ Quarkus 3.40 LTS เครื่องมือช่วยสร้างแอปด้วยภาษา Java สำหรับระบบบนคลาวด์ หรือระบบที่ทำงานบนเครื่องเซิร์ฟเวอร์ผ่านเครือข่าย (Quarkus)

สำหรับบริษัทที่ใช้เครื่องมือนี้ ประเด็นคือจะจัดเวลาทดสอบและดูแลงานจริงอย่างไรครับ ผมอ่านประกาศทางการกับรายงานข่าวประกอบกัน แต่ยังไม่ได้ทดสอบแอปจริง คำแนะนำด้านล่างจึงเป็นแนวทางจัดงาน ไม่ใช่ผลรับรองว่าแอปของคุณจะย้ายรุ่นได้ทันที

สรุป 30 วินาที: เกิดอะไรขึ้น

LTS ย่อจาก Long Term Support หมายถึงรุ่นที่มีการดูแลระยะยาวตามนโยบายโครงการ สำหรับรุ่นใหม่นี้ Quarkus ระบุระยะดูแลไว้ชัดเจน แทนที่จะให้ทีมเดาจากคำว่า “ระยะยาว” อย่างเดียว (Quarkus)

แกนหลักของรุ่นใหม่นี้ต่อเนื่องโดยตรงจาก Quarkus 3.39 แปลว่าฐานของมันมาจากรุ่นก่อนหน้า ไม่ใช่การเปลี่ยนระบบครั้งใหญ่ (Quarkus) ประกาศระบุด้วยว่ามีการแก้ไขเพิ่มเติมใน 3.40.1 แปลว่าเวลาเลือกแพ็กเกจจริงต้องดูรายละเอียดรุ่นย่อยด้วย (Quarkus)

อีกด้านหนึ่ง Quarkus เปิดตัว 4.0.0.Beta1 วันที่ 1 ตุลาคม 2026 ซึ่งเป็นรุ่นทดลองแรกของรุ่นใหญ่ถัดไป (ประกาศเบต้า Quarkus) คำว่าเบต้าหมายถึงยังอยู่ในช่วงให้ผู้ใช้ทดลองและส่งปัญหากลับไป ทีมโครงการวางแผนรุ่นสมบูรณ์ไว้ปลายเดือนพฤศจิกายน แต่ยังไม่ได้ระบุวันแน่นอน (Quarkus)

รุ่นใหม่กว่าแปลว่าควรย้ายงานจริงไปทันทีหรือครับ? คำตอบต้องเริ่มจากสถานะของรุ่นและงานที่ทีมต้องทดสอบ ข้อเท็จจริงเรื่อง LTS กับเบต้าให้ข้อมูลคนละอย่าง และยังไม่มีผลทดสอบแอปของบริษัทคุณในแหล่งข่าวเหล่านี้

ทำไมเรื่องนี้เกี่ยวกับคุณ

ถ้าคุณเป็นพนักงานทั่วไป ข่าวนี้ไม่ใช่คำสั่งให้เปลี่ยนเครื่องหรืออัปเดตมือถือครับ สิ่งที่ควรถามคือระบบของบริษัทใช้ Quarkus หรือไม่ ถ้าไม่ได้ใช้ ก็ไม่ควรนำข่าวนี้ไปสรุปว่าแอปทุกตัวต้องย้ายรุ่น

ลองใช้ระบบรับคำสั่งซื้อหรือระบบออกเอกสารเป็นตัวอย่างสมมติ หากบริษัทสร้างระบบนั้นด้วย Quarkus การเปลี่ยนรุ่นจะเป็นงานของทีมดูแลระบบ คุณอาจมีบทบาทช่วยตรวจว่าขั้นตอนทำงานเดิมยังใช้ได้ครบ โดยไม่ต้องจำชื่อเครื่องมือทั้งหมด

สำหรับเจ้าของธุรกิจเล็ก ผมแนะนำให้ขอแผนงานจากผู้รับจ้างมากกว่าขอคำรับรองสั้น ๆ ว่า “อัปแล้วครับ” แผนควรระบุว่าจะทดสอบอะไร ใครรับผิดชอบ และจะย้อนกลับอย่างไรหากพบปัญหา นี่เป็นข้อเสนอในการจัดงาน ไม่ใช่ข้อกำหนดใหม่ที่ Quarkus ประกาศ

สำหรับนักศึกษาหรือคนเพิ่งเริ่มพัฒนาแอป ข่าวนี้ช่วยแยกเป้าหมายการเรียนออกจากงานส่งลูกค้า คุณอาจทดลองรุ่นเบต้าเพื่อศึกษาทิศทางใหม่ได้ เพราะโครงการกำลังขอให้ผู้ใช้ช่วยทดสอบ (Quarkus) แต่ไม่ควรเอาผลจากตัวอย่างเล็ก ๆ ไปยืนยันแทนการทดสอบระบบงานจริง

ส่วนหัวหน้าทีมควรสนใจเงื่อนไขการย้ายมากที่สุด โครงการระบุว่าเครื่องมืออัปเดตช่วยจัดการงานส่วนใหญ่ได้ แต่ยังมีบางกรณีที่ต้องแก้ด้วยมือ (Quarkus) แปลว่าการมีเครื่องมือช่วยไม่ได้ทำให้เวลาตรวจงานเหลือศูนย์

ทำงานยังไง

มอง LTS เหมือนรถรุ่นปีที่คุณเลือกใช้ขับไปทำงาน และมีกรอบเวลารับบริการดูแลชัดเจนครับ รุ่นปีใหม่กว่าอาจน่าลอง แต่รถที่ใช้รับส่งคนทุกวันยังต้องผ่านการตรวจให้เหมาะกับงาน การเปรียบเทียบนี้อธิบายเรื่องแผนดูแล ไม่ได้หมายความว่าโครงการรับประกันทุกแอปเหมือนสัญญาซ่อมรถ

ในการย้ายรุ่น Quarkus แนะนำให้อัปเดต CLI ก่อน คำนี้หมายถึงเครื่องมือที่นักพัฒนาสั่งงานด้วยการพิมพ์คำสั่ง จากนั้นใช้คำสั่ง quarkus update เพื่อช่วยปรับแอปไปยัง LTS ใหม่ (Quarkus) ผมไม่ได้รันคำสั่งนี้กับระบบใดในบทความ จึงยังยืนยันผลเฉพาะโครงการของคุณไม่ได้

ประกาศบอกว่าเครื่องมือนี้อัปเดตแอปจาก Quarkus รุ่นใดก็ได้ รวมถึงสาย 2.x แปลว่าไม่ได้จำกัดให้เริ่มจากรุ่นก่อนหน้าเท่านั้น (Quarkus) แต่คำว่า “อัปเดตได้” ต้องอ่านควบคู่กับคำเตือนเรื่องงานที่ต้องทำเอง ไม่ใช่คำสัญญาว่ารันครั้งเดียวแล้วพร้อมใช้งานทุกกรณี

ถ้าเริ่มจากรุ่นก่อนหน้าทันที โครงการบอกว่าไม่มีขั้นตอนย้ายเพิ่มเติม เพราะ LTS ใหม่เป็นการต่อเนื่องโดยตรง (Quarkus) คำแนะนำของผมคือยังต้องทดสอบพฤติกรรมที่สำคัญกับธุรกิจ เพราะประกาศการย้ายรุ่นไม่ได้เป็นผลตรวจระบบของเรา

แต่ถ้าเริ่มจาก LTS ก่อนหน้าอย่าง 3.33 แปลว่าต้องตรวจการเปลี่ยนแปลงระหว่างทางด้วย (Quarkus) โครงการให้ไล่อ่านคู่มือย้ายตั้งแต่ 3.34–3.40 แปลว่าอย่าอ่านเฉพาะประกาศปลายทางแล้วข้ามรายละเอียดที่สะสมมา (Quarkus) คู่มือของรุ่นปลายทางว่างเพราะต่อเนื่องจากรุ่นก่อนหน้า แต่คู่มือระหว่างทางยังเป็นส่วนที่โครงการแนะนำให้อ่าน

จุดหักมุม: รุ่นใหญ่มีให้ลอง แต่ไม่จำเป็นต้องรีบย้ายงานจริง

แต่รุ่นใหญ่ที่เปิดให้ลองไม่ได้มาพร้อมสถานะ LTS ในประกาศเบต้าครับ โครงการกำลังขอให้นักพัฒนาส่วนเสริมย้ายงาน และให้ผู้ใช้ช่วยทดสอบแอป (Quarkus) นั่นคือคำเชิญให้ตรวจความพร้อม ไม่ใช่ผลตรวจว่าระบบของทุกบริษัทพร้อมแล้ว

ผมมองว่า ทีมส่วนใหญ่ที่ต้องดูแลงานจริงควรประเมินการลงที่ LTS ใหม่ก่อน แล้วแยกการทดลองรุ่นใหญ่ออกไปต่างหาก นี่เป็นความเห็นของผม ไม่ใช่คำสั่งจากโครงการ และทีมที่มีเหตุผลเฉพาะอาจเลือกต่างกันได้

อีกจุดที่อย่าข้ามคือเลขรุ่นในข่าวอิสระ InfoQ เขียน 3.34.0 ในย่อหน้า Quarkus แต่ท้ายย่อหน้าอ้างถึงบันทึกการออกรุ่นชุดใหม่ (InfoQ) แปลว่ารายงานชิ้นนี้มีข้อมูลที่ไม่ตรงกันภายในข้อความ ต้องเทียบประกาศต้นทางก่อนนำไปวางแผน

เรื่องเงิน / ผลกระทบ

แหล่งข่าวไม่ได้ให้ตัวเลขว่าอัปเดตแล้วบริษัทไทยจะประหยัดเงินเท่าไร จึงยังสรุปไม่ได้ว่าจะลดค่าคลาวด์หรือค่าแรงครับ สำหรับการจัดงบ ผมแนะนำให้แยกเวลาย้ายรุ่น เวลาทดสอบ และเวลาตรวจรับออกจากกัน อย่านับแค่เวลารันเครื่องมืออัปเดต

อีกส่วนที่ควรตรวจคือ องค์ประกอบแพลตฟอร์ม หมายถึงชิ้นส่วนซอฟต์แวร์ที่มีการอัปเกรดในชุดนี้ รายการทางการระบุชื่อและรุ่นดังต่อไปนี้ แต่ไม่ได้แปลว่าทุกแอปใช้งานทุกชิ้น (รายการ Quarkus) ตารางนี้มีไว้เทียบกับรายการของทีม ไม่ใช่รายการให้ติดตั้งเพิ่มทั้งหมด

องค์ประกอบ	รุ่นที่ประกาศ	ความหมายสำหรับการตรวจงาน
Camel Quarkus	3.40.0	ถ้าใช้อยู่ ให้ตรวจรายการนี้ในแผนย้าย
Quarkus CXF	3.40.0	ถ้าใช้อยู่ ให้ตรวจรายการนี้ในแผนย้าย
Quarkus LangChain4j	1.13.3	เทียบชื่อแพ็กเกจนี้โดยตรงก่อนอ้างเลขรุ่น
Quarkus MCP Server	2.0.1	ถ้าใช้อยู่ ให้ตรวจรายการนี้ในแผนย้าย
Quarkus Amazon Services	3.22.1	ถ้าใช้อยู่ ให้ตรวจรายการนี้ในแผนย้าย
Debezium	3.6.3.Final	เก็บชื่อรุ่นเต็มให้ตรงกับประกาศ
Quarkus Google Cloud Services	2.24.0	ถ้าใช้อยู่ ให้ตรวจรายการนี้ในแผนย้าย
Quarkus Operator SDK	7.8.0	ถ้าใช้อยู่ ให้ตรวจรายการนี้ในแผนย้าย
Quarkus Vault	4.10.0	ถ้าใช้อยู่ ให้ตรวจรายการนี้ในแผนย้าย
Quarkus Qpid JMS	2.14.0	ถ้าใช้อยู่ ให้ตรวจรายการนี้ในแผนย้าย

อีกตัวอย่างคือ JobRunr 9 ซึ่งประกาศทางการระบุว่ารองรับ LTS ใหม่ตั้งแต่วันแรก แปลว่ามีเครื่องมือในระบบนิเวศที่ตามรุ่นนี้ทันแล้ว (Quarkus) InfoQ รายงานการรองรับรุ่นใหม่นี้เช่นกัน แต่ข่าวนั้นยังไม่ใช่ผลทดสอบชุดโปรแกรมของบริษัทคุณ (InfoQ)

ส่วนรุ่นใหญ่มีการเปลี่ยนฐานเป็น Java 21 แปลว่าทีมต้องตรวจสภาพแวดล้อมที่ใช้รันแอปด้วย (Quarkus) โครงการระบุว่าแนวทางย้ายรุ่นใหญ่มีรายละเอียดมากกว่าการย้ายรุ่นย่อยตามปกติ (Quarkus) แต่ไม่มีจำนวนชั่วโมงที่ทุกทีมจะใช้เท่ากัน จึงควรประเมินจากงานของตัวเอง

ข้อมูลที่ยังไม่ชัด และจุดที่แหล่งข่าวพูดไม่ตรงกัน

ฝั่งที่สนับสนุนการย้ายไป LTS คือทีม Quarkus เอง ประกาศแนะนำเครื่องมืออัปเดตและบอกว่าช่วยรับภาระงานส่วนใหญ่ได้ (Quarkus) ส่วนข้อทักท้วงต่อการคิดว่า “จบอัตโนมัติ” ก็มาจากประกาศเดียวกัน ซึ่งเตือนว่ายังมีกรณีต้องทำเอง ผมจึงไม่ยกแหล่งนี้มาเป็นคำรับรองความง่ายเพียงด้านเดียว

สำหรับรุ่นใหญ่ Guillaume Smet ผู้เขียนประกาศ Quarkus เชิญผู้ใช้ให้ทดลองและรายงานปัญหา (Quarkus) แต่เขาระบุด้วยว่ารุ่นใหญ่มาพร้อมการเปลี่ยนแปลงจำนวนมากและคู่มือย้ายที่หนาแน่นกว่าเดิม แหล่งที่ให้มาไม่มีองค์กรอิสระออกมาคัดค้าน LTS หรือแนะนำให้ทุกทีมข้ามไปเบต้า จึงไม่ควรแต่งเสียงค้านขึ้นมา

จุดที่ข่าวไม่ตรงกันชัดที่สุดคือเลขรุ่นในรายงาน InfoQ บรรทัดเปิดของย่อหน้า Quarkus ใช้เลขรุ่นเก่า แต่บรรทัดอ้างอิงท้ายย่อหน้าชี้ไปยังบันทึกรุ่นใหม่ (InfoQ) ประกาศทางการระบุชัดว่า LTS ใหม่คือรุ่นในพาดหัวบทความนี้ (Quarkus) ผมยึดประกาศทางการเรื่องเลขรุ่น และยังยืนยันไม่ได้ว่าเหตุใดข้อความของ InfoQ จึงต่างกัน

อีกจุดคือ InfoQ รายงานข่าว LangChain4j 1.21.0 แยกไว้ต่างหาก แปลว่าเป็นข่าวของรายการชื่อนี้ในบทความรวมข่าว (InfoQ) อย่านำเลขนั้นไปแทนรุ่นของ Quarkus LangChain4j ในตารางข้างบน เพราะประกาศ Quarkus ระบุชื่อและเลขรุ่นขององค์ประกอบตัวเองไว้ต่างกัน (Quarkus)

ส่วนเรื่องที่ยังไม่รู้คือวันออกจริงของรุ่นสมบูรณ์ โครงการบอกเพียงแผนปลายเดือนพฤศจิกายน ไม่ใช่วันเปิดตัวที่ล็อกแล้ว (Quarkus) แหล่งที่ให้มายังไม่มีราคาแพ็กเกจดูแลเชิงพาณิชย์ในไทย หรือรายละเอียดข้อตกลงบริการเฉพาะบริษัท จึงห้ามอ่านระยะดูแลของโครงการเป็นคำรับรองเวลาซ่อมระบบของผู้รับจ้าง

แล้วแอปของบริษัทคุณต้องแก้ด้วยมือมากแค่ไหน? ยังตอบจากข่าวไม่ได้ครับ ประกาศบอกว่ามีกรณีเช่นนั้น แต่ไม่ได้สำรวจโค้ดหรือส่วนเสริมของทีมคุณ (Quarkus) สิ่งที่ต้องหาเพิ่มจึงเป็นผลตรวจจากระบบของตัวเอง ไม่ใช่คำโฆษณาว่าเครื่องมือทำได้ทุกอย่าง

แล้วเราควรทำอะไร

คนทั่วไปและเจ้าของกิจการ: ทำตามได้เลย

1. ถามผู้ดูแลว่าระบบที่ใช้อยู่เกี่ยวข้องกับ Quarkus หรือไม่ ขอชื่อระบบและผู้รับผิดชอบให้ชัดก่อนนัดอัปเดต
2. ถ้าเกี่ยวข้อง ให้ขอแผนทดสอบขั้นตอนที่คุณใช้งานจริง เช่น ตัวอย่างสมมติเรื่องรับคำสั่งซื้อหรือออกเอกสาร ระบุผลที่ยอมรับได้ก่อนเริ่มงาน
3. ขอช่วงเวลาทำงานและวิธีย้อนกลับจากผู้ดูแล อย่าอนุมัติจากคำว่า LTS เพียงคำเดียว เพราะแหล่งข่าวไม่ได้รับรองระบบเฉพาะของคุณ

หัวหน้าทีมและฝ่าย IT: ทำตามได้เลย

1. จดรุ่นปัจจุบันและรายการองค์ประกอบที่ใช้งานจริง เทียบกับประกาศทางการก่อนกำหนดขอบเขตงาน (Quarkus)
2. แยกงานย้ายไป LTS ออกจากงานทดลองเบต้า ให้แต่ละงานมีเจ้าของและเกณฑ์ตรวจรับของตัวเอง การแยกนี้เป็นคำแนะนำจัดงานของผม
3. ถ้ามาจาก LTS ก่อนหน้า ให้มอบหมายคนอ่านคู่มือทุกช่วงที่ประกาศแนะนำ แล้วสรุปเฉพาะการเปลี่ยนแปลงที่เกี่ยวข้องกับแอป (Quarkus)
4. กันเวลาสำหรับงานที่เครื่องมือไม่จัดการให้ และบันทึกผลทดสอบก่อนปล่อยระบบ อย่าให้คนรับผิดชอบต้องเดาว่า “อัปเดตสำเร็จ” หมายถึงผ่านงานธุรกิจแล้วหรือยัง

นักพัฒนาและผู้ดูแลส่วนเสริม: ทำตามได้เลย

1. อัปเดตเครื่องมือ CLI ตามคำแนะนำโครงการก่อนใช้เครื่องมือย้ายรุ่น ตรวจสิ่งที่เปลี่ยนในโครงการและอ่านคู่มือควบคู่กัน (Quarkus)
2. ทดลองกับสำเนาโครงการก่อน แล้วแยกรายการที่เครื่องมือแก้ให้จากรายการที่ต้องทำเอง บันทึกปัญหาที่พบเพื่อให้เพื่อนร่วมทีมตรวจต่อได้
3. ถ้าดูแลส่วนเสริมของ Quarkus ให้เริ่มประเมินการย้ายสู่รุ่นใหญ่ เพราะโครงการระบุว่าช่วงนี้ต้องการให้ผู้ดูแลส่วนเสริมลงมือเตรียมงาน (Quarkus)
4. ทดสอบเบต้าในงานที่แยกจากระบบลูกค้า และส่งปัญหาผ่าน GitHub ตามช่องทางที่โครงการขอไว้ ระบุสิ่งที่ทดลองจริง แทนการสรุปว่ารุ่นใหญ่ใช้ไม่ได้ทั้งหมด (Quarkus)

ผมมองว่า…

ผมมองว่า เรื่องนี้ ไม่ใช่การแข่งว่าใครใช้เลขรุ่นสูงกว่า แต่คือการเลือกแผนดูแลที่ทีมรับผิดชอบได้ สำหรับทีมส่วนใหญ่ที่มีงานลูกค้าอยู่ การประเมิน LTS ก่อนช่วยตั้งคำถามเรื่องขอบเขตและการตรวจรับให้เป็นรูปธรรม ส่วนเบต้าควรมีพื้นที่ให้ทดลองโดยไม่เอาผลลองมาแทนผลตรวจงานจริง

ผมมองว่า ข้อยกเว้นที่ควรให้ความสำคัญคือทีมดูแลส่วนเสริม เพราะประกาศรุ่นใหญ่กำลังขอให้กลุ่มนี้เริ่มย้ายและส่งข้อคิดเห็น (Quarkus) การรออย่างเดียวอาจไม่ตรงกับบทบาทของทีมกลุ่มนี้ แต่ยังควรแยกการเตรียมความพร้อมออกจากการอนุมัติใช้งานจริง

ผมมองว่า สำหรับบริษัทไทย สิ่งที่ควรได้หลังอ่านข่าวคือรายการงานที่มีคนรับผิดชอบ จะเลือก LTS หรือทดลองรุ่นใหญ่ก็ต้องอธิบายเหตุผลได้กับคนที่ใช้ระบบทุกวัน แผนที่อ่านเข้าใจง่ายมีค่ากว่าคำว่า “ล่าสุด” ที่ไม่มีผลตรวจแนบครับ

ปิดท้าย: สิ่งที่ต้องจับตา

การเลือกเวอร์ชันควรเริ่มจากงานที่ต้องดูแลต่อเนื่องและหลักฐานว่าทดสอบผ่าน สิ่งแรกที่ต้องจับตาคือแผนรุ่นสมบูรณ์ช่วงปลายเดือนพฤศจิกายน ซึ่ง Quarkus ยังระบุเป็นแผน ไม่ใช่วันยืนยัน (Quarkus) อีกสิ่งคือความพร้อมของส่วนเสริมที่ทีมใช้งานจริง เพราะโครงการกำลังขอให้ผู้ดูแลย้ายและช่วยทดสอบ

ถ้าทีมคุณจะย้ายรุ่นรอบนี้ ขั้นตอนงานใดต้องทดสอบให้ผ่านก่อนจึงจะกล้าปล่อยให้ลูกค้าใช้?

Recap

• เกิดอะไรขึ้น: Quarkus ออกรุ่น LTS ใหม่ และมีรุ่นใหญ่สถานะเบต้าให้ทดลองตามประกาศแยกกัน
• ตัวเลขที่ต้องจำ: ระยะดูแล 12 เดือน แปลว่ามีกรอบหนึ่งปีตามประกาศโครงการ ไม่ใช่รายละเอียดสัญญาบริการบริษัท
• ข้อมูลไม่ตรงกัน: InfoQ ใช้เลขรุ่นเก่าในย่อหน้า แต่ท้ายย่อหน้าอ้างบันทึกรุ่นใหม่ ให้ยึดประกาศ Quarkus เรื่องเลขรุ่น
• เสียงสองด้าน: Quarkus บอกว่าเครื่องมือช่วยงานส่วนใหญ่ได้ และเตือนเองว่ายังมีกรณีต้องทำด้วยมือ ไม่มีเสียงค้านอิสระในแหล่งที่ให้มา
• ยังไม่รู้: วันออกจริงของรุ่นสมบูรณ์ ราคาแพ็กเกจดูแลในไทย และเวลาย้ายแอปเฉพาะบริษัท
• ผลต่อคุณ: ถ้าระบบใช้ Quarkus ให้ขอแผนทดสอบ ผู้รับผิดชอบ และวิธีย้อนกลับ ก่อนอนุมัติเปลี่ยนงานจริง
• สิ่งที่ต้องจับตา: แผนรุ่นสมบูรณ์ปลายเดือนพฤศจิกายน และผลทดสอบส่วนเสริมที่ทีมใช้
• แหล่งข่าว: 1 — ประกาศ LTS · 2 — InfoQ รวมข่าว Java · 3 — ประกาศเบต้า