Spring Boot 4.1.2 และ 4.0.9 มาแล้ว ส่วน 4.2 RC1 ให้ลองก่อนใช้จริง

Spring Boot มีรุ่นใหม่ให้แยกดู 3 รุ่นในรายการเผยแพร่วันที่ 22 ตุลาคม 2026 ได้แก่ 4.1.2, 4.0.9 และ 4.2.0-RC1 โดยสองรุ่นแรกเน้นงานบำรุงรักษา ส่วนรุ่นท้ายมีการเปลี่ยนแปลงสำหรับสาย 4.2 ที่ยังอยู่ระหว่างทดสอบ (GitHub) สำหรับคนดูแลระบบ ประเด็นจึงอยู่ที่เลือกอัปเดตให้ตรงกับงาน เพราะรายการแก้ไขมีทั้งการเชื่อมต่อฐานข้อมูล การตรวจสิทธิ์เข้าใช้งาน และการปิดบริการที่อาจค้างได้ (GitHub)

คนใช้เว็บทำงานหรือเจ้าของร้านไม่จำเป็นต้องจำเลขรุ่นทั้งหมดครับ แต่ควรส่งข่าวนี้ให้คนดูแลระบบตรวจว่าใช้อยู่สายไหน คำแนะนำของผมคือ ระบบที่ใช้จริงบน 4.1.x ให้ทดสอบอัปเดตเป็น 4.1.2 ส่วน 4.0.x ให้ไป 4.0.9 พร้อมวางแผนรุ่นถัดไป สำหรับ 4.2.0-RC1 ให้แยกพื้นที่ทดลองก่อน เหตุผลสำคัญคือ RC ยังเป็นรุ่นให้ช่วยกันทดสอบก่อนรุ่นพร้อมใช้ทั่วไป ตามคำอธิบายในบทความตรวจสอบการย้ายรุ่นของ Ankurm (Ankurm)

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

Spring Boot คือเครื่องมือช่วยสร้างแอปด้วย Spring ในโลก Java โดยลดงานตั้งค่าที่นักพัฒนาต้องจัดการเอง โครงการอธิบายเป้าหมายว่าใช้สร้างแอปและบริการที่พร้อมสำหรับงานจริงได้โดยมีความยุ่งยากน้อยลง (GitHub) ข่าวรอบนี้มีสิ่งที่ต้องแยกกันดังนี้

• 4.1.2: แก้ข้อผิดพลาดหลายจุด พร้อมปรับชุดส่วนประกอบที่แอปใช้ เช่น Spring Framework 7.0.10, Spring Security 7.1.2 และ Tomcat 11.0.27 (NewReleases)
• 4.0.9: เป็นรอบบำรุงรักษาอีกสาย มีการแก้ปัญหาร่วมกับ 4.1.2 หลายรายการ และอัปเดตส่วนประกอบ เช่น Hibernate 7.2.25.Final กับ Hibernate Validator 9.0.2.Final (GitHub)
• 4.2.0-RC1: RC ย่อจาก release candidate หรือ “ตัวเกือบจริง ให้ลองก่อนเปิดขาย” ยังไม่ใช่ GA ซึ่งหมายถึงรุ่นพร้อมใช้ทั่วไป บทความรองระบุว่า ณ 22 ตุลาคม 2026 ยังไม่มี 4.2.0 รุ่น GA อยู่ในรายการที่ผู้เขียนตรวจ (Ankurm)

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

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

สำหรับพนักงานออฟฟิศหรือเจ้าของธุรกิจ จุดที่เข้าใจง่ายที่สุดคือการเข้าใช้ระบบ รายการแก้ไขของทั้ง 4.1.2 และ 4.0.9 ระบุปัญหาการปฏิเสธ JWT ซึ่งเป็นข้อมูลรับรองสิทธิ์แบบดิจิทัล ในกรณีที่การตั้งค่าตัวระบุผู้ออกข้อมูลรับรองว่าง แต่กำหนดแหล่งกุญแจตรวจสอบไว้แล้ว นี่เป็นกรณีเฉพาะในบันทึกรุ่น ไม่ได้แปลว่าทุกระบบล็อกอินมีอาการเดียวกัน (GitHub)

อีกกลุ่มเกี่ยวกับฐานข้อมูล ทั้งสองรุ่นแก้ปัญหา MongoDB เชื่อมต่อไม่ได้เมื่อข้อมูลรับรองมีช่องว่าง และแก้ปัญหาตรวจสอบตัวตนกับ Elasticsearch เมื่อรหัสผ่านในค่าการเชื่อมต่อมีเครื่องหมายทวิภาค หรือเครื่องหมายสองจุด นอกจากนี้ยังมีการแก้การเชื่อมต่อ MongoDB ผ่าน Docker Compose เมื่อข้อมูลรับรองมีอักขระที่ต้องแปลงรูปแบบก่อนใช้งาน (GitHub)

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

ฝั่งทีมไอทีก็มีเรื่องระหว่างนำระบบขึ้นใช้งาน ทั้ง 4.1.2 และ 4.0.9 แก้กรณีหยุด NettyWebServer แล้วค้างเมื่อสั่งหยุดทันทีหลังเริ่มกระบวนการปิดอย่างนุ่มนวล รวมถึงกรณี Tomcat หรือ Jetty รายงานว่ายังมีคำขอทำงานอยู่ ทั้งที่เซิร์ฟเวอร์ว่างในเงื่อนไขที่บันทึกรุ่นระบุ (GitHub) ผมจึงแนะนำให้ทดสอบทั้งตอนเปิดและตอนปิดบริการ การเปิดติดเพียงอย่างเดียวยังไม่ครอบคลุมรายการที่แก้มา

ทำงานยังไง

รุ่นบำรุงรักษาอย่าง 4.1.2 และ 4.0.9 รวมงานแก้บั๊กและการอัปเดต dependency ซึ่งหมายถึงส่วนประกอบซอฟต์แวร์ที่แอปเรียกใช้ร่วมกัน ส่วน 4.2.0-RC1 มีงานเปลี่ยนความสามารถและส่วนประกอบสำหรับรุ่นถัดไป บันทึกทางการระบุการขยับไป Spring Framework 7.1.0-RC1, Spring Security 7.2.0-RC1, Spring Data 2026.1.0-RC1 และ Micrometer 1.18.0-RC1 ซึ่งเป็นเครื่องมือเก็บตัวชี้วัดการทำงานของระบบ (GitHub, บันทึก RC1)

เปรียบเทียบแบบเดียวให้เห็นภาพ: 4.2 RC1 เหมือนรถรุ่นใหม่ก่อนเปิดตัวให้ลองขับในสนาม เรานำลักษณะงานของตัวเองไปลองได้ แต่การวิ่งผ่านสนามยังไม่ใช่เหตุผลให้เอารถคันนั้นไปรับงานทุกวันทันที คำอธิบายเรื่อง RC ของ Ankurm ก็ย้ำว่ารุ่นทดสอบอาจเปลี่ยนได้ และควรลองกับสำเนาแอปในสาขางานแยก (Ankurm)

สิ่งที่เปลี่ยนชัดใน RC1 คือ Buildpacks ซึ่งช่วยประกอบแอปให้เป็นอิมเมจ หรือชุดแอปพร้อมสภาพแวดล้อมสำหรับนำไปทำงาน เครื่องมือ Maven และ Gradle ที่ใช้สร้างแอปเปลี่ยนตัวประกอบตั้งต้นเป็น Ubuntu Resolute และอิมเมจเปลี่ยนฐานจาก Ubuntu 24.04 เป็น 26.04 ตามบันทึกทางการ (บันทึก RC1)

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

Docker Compose คือเครื่องมือจัดให้บริการหลายตัวเริ่มทำงานร่วมกัน สำหรับการเชื่อมกับเครื่องมือนี้ RC1 รองรับ virtual host ของ RabbitMQ ซึ่งเป็นการแบ่งพื้นที่ใช้งานภายในระบบรับส่งข้อความ และรองรับรหัสผ่าน root แบบสุ่มของ MariaDB กับ MySQL โดย root คือบัญชีผู้ดูแลฐานข้อมูล นอกจากนี้เครื่องมือแยกไฟล์แพ็กเกจรองรับ WAR ซึ่งเป็นรูปแบบบรรจุเว็บแอปแล้ว และรายการเผยแพร่ระบุการรองรับไลบรารีแบบ provided-scope ตอนแยก executable WAR หรือ WAR ที่สั่งทำงานได้ด้วย (บันทึก RC1, GitHub)

จุดสังเกต: หยุดตั้งแต่เริ่ม อาจช่วยให้เจอปัญหาเร็วขึ้น

RC1 เพิ่มตัวเลือกให้ properties migrator ซึ่งเป็นตัวช่วยตรวจค่าตั้งค่าที่เปลี่ยนระหว่างย้ายรุ่น สั่งให้แอปเริ่มทำงานไม่สำเร็จเมื่อพบข้อผิดพลาดหรือคำเตือนได้ (บันทึก RC1) สำหรับการทดสอบอัตโนมัติ ผมเห็นว่านี่เป็นตัวเลือกที่น่าสนใจ เพราะทีมสามารถกำหนดให้ประเด็นที่พบต้องได้รับการตรวจ ก่อนปล่อยขั้นตอนทดสอบให้ผ่านไป

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

เรื่อง deprecation หรือการประกาศว่าแนวทางเดิมควรเลิกใช้ในอนาคตก็ต้องแยกจากการถอดออกทันที ตามบทความรอง Spring Framework 7.1 ประกาศเลิกแนะนำ RestTemplate ซึ่งใช้เรียกบริการผ่านเว็บ และ Boot 4.2 ประกาศแบบเดียวกันกับตัวช่วยที่เกี่ยวข้อง ผู้เขียนรายงานว่าการทดสอบคอมไพล์บน RC1 ยังสำเร็จแต่มีคำเตือน พร้อมระบุ RestClient และตัวสร้างของมันเป็นแนวทางทดแทน ส่วนเครื่องมือทดสอบ TestRestTemplate มี RestTestClient เป็นตัวแทนตามเอกสารที่บทความอ้างถึง (Ankurm)

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

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

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

ใน 4.1.2 มีการอัปเดต Spring Framework เป็น 7.0.10, Spring Security เป็น 7.1.2, Hibernate เป็น 7.4.13.Final, Netty เป็น 4.2.19.Final และ Tomcat เป็น 11.0.27 ตามรายการเผยแพร่ที่ NewReleases นำมาแสดง ส่วน 4.0.9 ระบุ Hibernate 7.2.25.Final, Hibernate Validator 9.0.2.Final, Cassandra Driver 4.19.4 และ FreeMarker 2.3.35 ในข้อความ GitHub ที่ให้มา จึงไม่ควรคาดว่าทั้งสองสายจะได้ส่วนประกอบเลขเดียวกันทั้งหมด (NewReleases, GitHub)

ตัวอย่างงานที่ผมจะเผื่อเวลาตรวจคือ การเชื่อมต่อฐานข้อมูล การรับรองสิทธิ์ และการโหลดการตั้งค่า SSL ใหม่ โดย SSL คือการตั้งค่าการเชื่อมต่อแบบเข้ารหัส ทั้งสองรุ่นบำรุงรักษามีรายการแก้การปรับแต่ง SSL ของ Tomcat ที่สูญหายระหว่างเริ่มทำงานหรือโหลดชุดการตั้งค่าใหม่ ส่วน 4.1.2 ยังระบุการแก้ข้อมูลอักขระบางกลุ่มเสียหายเมื่อแปลง JSON ซึ่งเป็นรูปแบบข้อมูลที่ระบบแลกเปลี่ยนกัน (GitHub, NewReleases)

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

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

วันที่ในเอกสารมีหน้าที่ต่างกัน: รายการเผยแพร่ GitHub ที่ให้มาลงวันที่ 22 ตุลาคม 2026 ขณะที่หน้า wiki ของ RC1 ลงวันที่ 20 ตุลาคม 2026 ส่วน Ankurm ระบุว่า RC1 อยู่บน Maven Central ซึ่งเป็นแหล่งแจกจ่ายส่วนประกอบ Java แล้ว ณ 22 ตุลาคม จึงควรแยกวันที่เอกสารกับวันที่รายการเผยแพร่ ไม่สรุปว่าสองวันนั้นเป็นเหตุการณ์เดียวกัน ข้อความต้นทางไม่มีเวลาพร้อมเขตเวลา จึงไม่มีข้อมูลให้แปลงเป็นเวลาไทยที่ละเอียดกว่าวันที่ (GitHub, บันทึก RC1, Ankurm)

เลขส่วนประกอบ RC1 มีบางจุดไม่ตรงกัน: wiki ระบุ Caffeine ซึ่งเป็นส่วนประกอบเก็บข้อมูลชั่วคราวไว้ที่ 3.3.0 แต่รายการเผยแพร่ระบุ 3.3.1 อีกจุดคือ wiki ระบุ OpenTelemetry ซึ่งใช้เก็บข้อมูลติดตามการทำงานไว้ที่ 1.66.0 ขณะที่ Ankurm รายงานจากชุดส่วนประกอบในการทดสอบของผู้เขียนว่าเป็น 1.67.0 ตัวเลขหลังเป็นรายงานจากแหล่งรองแหล่งเดียว ผมจึงไม่เลือกเลขใดเลขหนึ่งมารับรองแทนทุกโครงการ และแนะนำให้ตรวจรุ่นที่แอปดึงมาใช้จริง (บันทึก RC1, GitHub, Ankurm)

กำหนดรุ่นพร้อมใช้ยังไม่ยืนยัน: Ankurm ระบุว่าผู้เขียนไม่พบวัน GA ของ Boot 4.2 ที่ประกาศแล้ว ส่วนกำหนดเดือนพฤศจิกายน 2026 ที่บทความกล่าวถึงเป็นของ Spring Framework 7.1 และบทความเองให้ถือว่ายังไม่ยืนยัน จึงนำไปใช้เป็นวันเปิดใช้ Boot 4.2 ไม่ได้ (Ankurm)

ข้อความ GitHub สำหรับ 4.0.9 ที่ให้มาจบระหว่างรายการอัปเดตส่วนประกอบ ขณะที่ส่วน 4.1.2 ในหน้าเดียวกันก็ไม่ครบทั้งหมด บทความนี้จึงใช้ NewReleases เสริมรายละเอียดของ 4.1.2 และไม่เติมเลขที่ขาดของ 4.0.9 เอง แหล่งข้อมูลชุดนี้ยังไม่มีวันสิ้นสุดการสนับสนุนแบบโอเพนซอร์สของสาย 4.0.x ไม่มีตัวเลของค์กรไทยที่ได้รับผลกระทบ และไม่มีข้อมูลพอจะจัดทุกรายการแก้บั๊กเป็นช่องโหว่ความปลอดภัย (GitHub, NewReleases)

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

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

ผู้ใช้ทั่วไป เจ้าของร้าน และผู้จัดการ

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

ทีมที่ใช้ 4.1.x ในระบบจริง

1. เตรียมอัปเดตเป็น 4.1.2 ผ่านสภาพแวดล้อมทดสอบก่อน โดยเทียบรายการแก้บั๊กกับเทคโนโลยีที่แอปใช้จริง (GitHub)
2. ตรวจส่วนประกอบที่เปลี่ยน โดยเฉพาะ Spring Framework, Spring Security, Tomcat และตัวเชื่อมฐานข้อมูลที่โครงการใช้งาน รายการ 4.1.2 มีการอัปเดตหลายส่วนพร้อมกัน (NewReleases)
3. ทดสอบการเริ่มและหยุดบริการ รวมถึงงานเข้ารหัสและรับรองสิทธิ์ที่เกี่ยวข้องกับแอป แล้วเก็บผลก่อนและหลังอัปเดตเพื่อให้ทีมตัดสินใจเปิดใช้ได้

ทีมที่ยังอยู่ 4.0.x

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

ทีมที่อยากลอง 4.2.0-RC1

1. เปิด branch หรือสาขาโค้ดแยก แล้วนำเข้า CI ซึ่งเป็นระบบสร้างและทดสอบโค้ดอัตโนมัติ ผมแนะนำให้ทดลองที่นี่ก่อน และยังไม่ใช้ RC1 ในระบบจริง เพราะสถานะ RC ยังเปิดให้ทดสอบและอาจเปลี่ยนแปลงได้ (Ankurm)
2. ตรวจตัวประกอบและอิมเมจรันจากการเปลี่ยนเป็น Ubuntu Resolute หากต้องสร้างผลลัพธ์เดิมซ้ำได้ ให้กำหนดรุ่นทั้งสองส่วนตามคำแนะนำทางการ (บันทึก RC1)
3. ลองคุณสมบัติ Docker Compose เฉพาะที่ใช้จริง ทั้ง virtual host ของ RabbitMQ และรหัสผ่านผู้ดูแลแบบสุ่มของ MariaDB หรือ MySQL พร้อมทดสอบการแยก WAR หากกระบวนการส่งมอบแอปใช้รูปแบบนี้ (บันทึก RC1)
4. ใช้ตัวช่วยตรวจค่าตั้งค่าร่วมกับการอ่านรายการเปลี่ยนแปลง และพิจารณาตัวเลือกหยุดเริ่มแอปเมื่อพบประเด็น อย่าถือว่ารายงานสะอาดรับรองทุกค่า ส่วนรายการเลิกใช้ RestTemplate ให้แยกประเมินงานย้ายไป RestClient (บันทึก RC1, Ankurm)

ผมมองว่า…

ผมมองว่า ความเห็นของผมต่อรอบนี้คือ ไม่ใช่การแข่งขันใช้เลขรุ่นล่าสุด แต่คือการเลือกจังหวะอัปเดตให้เหมาะกับงาน ทีมที่ใช้ 4.1.x หรือ 4.0.x มีรายการแก้บั๊กชัดเจนให้ตรวจ ส่วนคนอยากเตรียมรับ 4.2 ก็มี RC1 ให้ลองกับโค้ดและวิธีสร้างแอปของตัวเองแล้ว (GitHub)

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

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

สิ่งที่ควรตามต่อคือประกาศรุ่นพร้อมใช้ของ Boot 4.2 และบันทึกรุ่นฉบับถัดไป โดยเฉพาะรุ่นส่วนประกอบที่ข้อมูลยังไม่ตรงกัน รวมถึงคำแนะนำเรื่องค่าตั้งค่าที่ต้องย้าย ขณะนี้ Ankurm ยังรายงานว่าไม่พบวัน GA ของ Boot 4.2 ที่ประกาศแล้ว จึงควรวางแผนทดลองจากความพร้อมของทีมก่อนผูกวันเปิดใช้จริง (Ankurm)

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

Recap

• ตรวจว่าแอปใช้ Spring Boot สายไหน และใครรับผิดชอบการอัปเดต
• ระบบจริงบน 4.1.x เตรียมทดสอบอัปเดตเป็น 4.1.2
• ระบบจริงบน 4.0.x เตรียมทดสอบ 4.0.9 พร้อมแผนย้ายสาย
• แยกทดลอง 4.2.0-RC1 ใน branch และ CI ก่อนใช้จริง
• ตรวจงานรับรองสิทธิ์ ฐานข้อมูล และการเริ่มกับหยุดบริการตามที่แอปใช้
• ตรวจ Ubuntu Resolute และกำหนดรุ่นอิมเมจให้ชัดหากต้องสร้างซ้ำได้
• อ่านคำเตือนค่าตั้งค่าควบคู่รายการเปลี่ยนแปลง และประเมินงานเลิกใช้ RestTemplate
• รอประกาศ GA ที่ยืนยันแล้ว และตรวจเลขส่วนประกอบจากแอปที่สร้างจริง