เลขเวอร์ชั่นจะใส่ผ่าน tags ของ Docker image ใช้รูปแบบ Semantic ซึ่งสมาชิกในทีมจะเป็นคนกำหนด จะอยู่ในรูปของ X.X.X

Frontend

รูปแบบ x.x.x ตัวอย่างเช่น 1.2.3

• Major (Major.x.x อยู่หน้าสุด) เช่น 1 ในตัวอย่าง คือ เลขจะมีการอัปเดตเมื่อมีการเปลี่ยนแปลงครั้งใหญ่ เช่น เพิ่มความสามารถ (feature) ขนาดใหญ่ หรือเปลี่ยนเครื่องมือ
• Minor (x.Minor.x อยู่ตรงกลางระหว่างจุดตัวแรกและตัวที่สอง) เช่น 2 ในตัวอย่าง คือ เลขจะมีการอัปเดตเมื่อมีการเพิ่มความสามารถ (feature) เล็กน้อยที่ไม่กระทบของเดิมที่มีอยู่
• Patch (x.x.Patch อยู่หลังสุด) เช่น 3 ในตัวอย่าง คือ เลขจะมีการอัปเดตเมื่อมีการแก้ไขข้อผิดพลาดของระบบ

Backend

รูปแบบ x.x.x ตัวอย่างเช่น 1.2.3

• Major (Major.x.x อยู่หน้าสุด) เช่น 1 ในตัวอย่าง คือ เลขจะมีการอัปเดตเมื่อมีการเปลี่ยนแปลงครั้งใหญ่ เช่น เพิ่ม API หรือเปลี่ยนวิธีการเรียกใหม่
• Minor (x.Minor.x อยู่ตรงกลางระหว่างจุดตัวแรกและตัวที่สอง) เช่น 2 ในตัวอย่าง คือ เลขจะมีการอัปเดตเมื่อมีการปรับปรุงหรือเปลี่ยนแปลง API ตัวเก่า
• Patch (x.x.Patch อยู่หลังสุด) เช่น 3 ในตัวอย่าง คือ เลขจะมีการอัปเดตเมื่อมีการแก้ไขข้อผิดพลาดของระบบ

กฎอื่น ๆ

• ถ้าเลข Minor เปลี่ยน เลข Patch ต้องถูก reset เป็น 0
• ถ้าเลข Major เปลี่ยน เลข Minor และเลข Patch ต้องถูก reset เป็น 0

ข้อดีและข้อเสียของการจัดการ versioning

ข้อดี

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

ข้อเสีย

• ต้องทำแบบ manual ทุกอย่าง
• อาจมีข้อผิดพลาดเกิดขึ้นได้ จากการที่สมาชิกในทีมไม่เข้าใจในในเรื่องของ Semantic Versioning

การปรับปรุงข้อเสีย

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