มาตรฐานการตั้งเลข version ของ software

มาตรฐานการตั้งเลข version ของ software

ผมเองเป็นคนหนึ่ง ที่เวลาตั้ง software version number แล้วก็ตั้งตามใจเลย alpha บ้าง beta บ้าง 1.0 บ้าง ก็ว่ากันไป เรียกง่ายๆว่ามั่วนั่นแหล่ะซึ่งจริงๆแล้วเค้ามีมาตรฐานกำหนดเอาไว้อยู่แล้ว วันนี้ จะหยิบขึ้นมาตัวหนึ่ง ที่ผมก็คิดว่าเข้าใจได้ง่ายดี นั่นคือ semver ตอนที่เขียนนี้เป็น version 2.0.0-rc.1 อยู่ แสดงว่า มันก็ไม่ใช่เรื่องใหม่ และน่าจะมีคนเอาไปใช้แล้วมากพอสมควร

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


โดยมาตรฐาน semver เค้ากำหนดเอาไว้ดังนี้ครับ

  1. software ที่ใช้ semantic versioning จะต้อง ประกาศ public API เอาไว้ ไม่ว่าจะเป็นในโค้ดเอง หรือใน document ก็ได้
  2. มาตรฐานโดยปกติ จะเขียน X.Y.Z โดยต้องไม่เป็นเลขติดลบ X คือ version หลัก (major version) Y คือ version ย่อย (minor version) และ Z คือ version ปรับปรุง (patch version) โดยจะต้องใช้การเพิ่มค่าที่ละ 1 เช่น 1.9.0 > 1.10.0 > 1.11.0
  3. เมื่อมีการเพิ่มเลข major version ตัวเลข minor , patch จะต้อง reset เริ่มต้นที่ 0 และเมื่อ เพิ่มเลขที่ minor version เลขที่ patch ต้องเริ่มต้นที่ 0 เช่น 1.1.3 > 2.0.0 หรือ 2.1.7 > 2.2.0
  4. เมื่อ version ถูก release แล้ว content ที่อยู่ใน version จะต้องไม่ถูกแก้ไขอีก หากมีการแก้ไขใดๆ ให้นับเป็น version ถัดไปทันที
  5. Major version ที่เป็น 0 (เช่น 0.y.z) แปลว่า อยู่ในช่วงการพัฒนา ทุกสิ่งอย่างสามารถเพิ่มขึ้นมา หรืออยู่ดีๆหายไปก็ได้ เป็นอันรู้กันว่า ยังไม่เหมาะกับงานที่ซีเรียสมากๆ
  6. Version 1.0.0 ที่ประกาศ public แล้ว หากมีการพัฒนา version ใหม่ จะต้องประกาศการเปลี่ยนแปลง สิ่งที่เปลี่ยนไปจากเดิมด้วย
  7. Patch version Z (x.y.Z โดย x > 0) จะต้องเพิ่มเมื่อมีการแก้ไขแบบที่ยังใช้งานร่วมกับ version ก่อนหน้า หรือ ปัจจุบัน ที่กำลังใช้งานอยู่ได้ หรือ การแก้ไขบางจุด ที่ทำงานผิดปกติ หรือผลลัพท์เพี้ยนๆไป
  8. Minor version y (x.Y.z โดย x > 0) จะต้องเพิ่มเมื่อมีการเพิ่ม function การทำงาน  และยังทำงานร่วมกับ version ก่อนหน้า หรือปัจจุบัน ที่กำลังใช้งานอยู่ได้ หรือว่า กรณีที่ปิดบาง function ออกไป หรือว่า การเพิ่ม function การทำงานใหม่ หรือ ปรับปรุงการทำงานเชิงลึก(ที่ไม่สามารถเผยต่อ public ได้) หรืออาจจะรวมการเพิ่มของ path version เข้ามาเลย แต่ว่า การเพิ่ม minor version จะต้องเริ่ม reset patch version ไปที่ 0 ก่อนเสมอ
  9. Major version (X.y.z โดย x >0) จะต้องเพิ่มเมื่อ มีการทำ version ใหม่ที่ไม่สามารถใช้งานร่วมกับ version เก่าได้ โดยอาจจะรวม minor ,patch มาพร้อมกันเลยก็ได้ แต่ว่า ทั้ง minor , patch จะต้องเริ่ม reset ไปที่ 0 ก่อนเสมอ
  10. Pre-release version อาจจะใช้เครื่องหมาย dash แล้ว identifiers  แล้วตามด้วย dot คั่นใน series นั้นๆได้ โดยตัวที่ identifiers จะรันด้วยตัวหนังสือใน ASCII  และ dash เท่านั้น [0-9A-Za-z-]  ตัวอย่าง 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92
  11. Build version อาจจะใช้เครื่องหมาย + แล้ว identifiers แล้วตามด้วย dot คั่นใน series นั้นๆได้ โดยที่ตัว identifiers จะรันด้วยตัวหนังสือใน ASCII  และ dash เท่านั้น [0-9A-Za-z-]  ตัวอย่าง 1.0.0+build.1,1.3.7+build.11.e0f985a
  12. การเรียงลำดับ version จะต้องคำนวณตามลำดับดังนี้ major, minor ,patch, pre-release และ build เอง ก็จะมีการเรียงลำดับได้อีก ดังนี้ major, minor , patch โดยอาศัยการเรียงค่ามากกว่าน้อยกว่า สำหรับการใช้ identifiers ก็จะเรียงตามลำดับของตัวหนังสือ และจะถือว่า ตัวหนังสือมีลำดับที่สำคัญกว่าตัวเลข เช่น 1.0.0-alpha < 1.0.0.-alpha.1 < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0-rc.1+build.1 < 1.0.0 < 1.0.0+0.3.7 < 1.3.7+build < 1.3.7+build.2.b8f12d7 < 1.3.7+build.11.e0f985a

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

Create: Modify : 2013-03-29 09:00:52 Read : 6934 URL :