ชุมชนนักพัฒนาซอฟต์แวร์กำลังคึกคักกับการพูดคุยเกี่ยวกับ Pride Versioning ซึ่งเป็นแนวทางที่มีอารมณ์ขันในการกำหนดหมายเลขเวอร์ชันของซอฟต์แวร์ที่เปลี่ยนจาก semantic versioning แบบดั้งเดิมมาเป็นแนวทางที่สื่อถึงอารมณ์ความรู้สึกได้ตรงไปตรงมามากขึ้น ระบบทางเลือกนี้สร้างขึ้นโดย Niki Tonsky โดยใช้รูปแบบ PROUD.DEFAULT.SHAME แทนโครงสร้าง major.minor.patch แบบเดิม
การเปรียบเทียบรูปแบบ Pride Versioning
| ระบบการกำหนดเวอร์ชัน | รูปแบบ | ตัวอย่าง | ลักษณะเฉพาะสำคัญ |
|---|---|---|---|
| Pride Versioning | PROUD.DEFAULT.SHAME | 2.7.123 | การเพิ่มขึ้นตามอารมณ์ |
| Semantic Versioning | MAJOR.MINOR.PATCH | 2.7.123 | ตามผลกระทบทางเทคนิค |
| Calendar Versioning | YYYY.MM.DD | 2020.12.07 | การปล่อยตามวันที่ |
| OpenSSL System | MAJOR.MINOR.LETTER | 1.1.1a | กฎความเข้ากันได้แบบกำหนดเอง |
 |
|---|
| รูปภาพนี้แสดงระบบ Pride Versioning โดยเน้นให้เห็นว่าหมายเลขเวอร์ชันสามารถสะท้อนความผูกพันทางอารมณ์กับการเปลี่ยนแปลงในการพัฒนาได้อย่างไร |
ชุมชนเปิดเผยแนวปฏิบัติในการกำหนดเวอร์ชันแบบแปลกๆ ในโลกจริง
แนวคิด Pride Versioning ได้กระตุ้นให้นักพัฒนาแบ่งปันตัวอย่างของระบบการกำหนดเวอร์ชันที่ไม่เป็นไปตามแบบแผนที่โปรเจกต์ใหญ่ๆ ใช้อยู่แล้ว นโยบายการกำหนดเวอร์ชันของ OpenSSL โดดเด่นเป็นพิเศษด้วยความแปลกประหลาดสำหรับซอฟต์แวร์โครงสร้างพื้นฐานที่สำคัญเช่นนี้ ระบบของพวกเขาใช้การปล่อย major releases สำหรับการเปลี่ยนแปลงที่ทำลาย compatibility, minor releases สำหรับการเพิ่มฟีเจอร์ที่รักษา binary compatibility ไว้ และ letter releases สำหรับการแก้ไขบั๊กและปัญหาความปลอดภัยเท่านั้น แนวทางนี้แตกต่างอย่างมากจาก semantic versioning มาตรฐาน แต่กลับใช้งานได้ดีกับซอฟต์แวร์ที่มีความสำคัญด้านความปลอดภัยมากที่สุดชิ้นหนึ่งในโลกคอมพิวเตอร์
ประวัติการกำหนดเวอร์ชันของ Ruby เป็นอีกหนึ่งกรณีศึกษาที่น่าสนใจ ภาษานี้เคยใช้สิ่งที่พวกเขาเรียกว่า Semantic Versioning แต่มีจุดพิเศษ - minor versions จะถูกปล่อยในทุกวันคริสต์มาสในญี่ปุ่น โดยไม่คำนึงถึง API compatibility แนวทางที่อิงตามปฏิทินนี้ให้ความสำคัญกับการกำหนดเวลาปล่อยที่คาดเดาได้มากกว่าข้อพิจารณาทางเทคนิค แม้ว่า Ruby จะได้เปลี่ยนมาใกล้เคียงกับแนวปฏิบัติ semantic versioning แบบดั้งเดิมมากขึ้นแล้วก็ตาม
แนวทางการกำหนดเวอร์ชันทางเลือกได้รับความสนใจ
การพูดคุยครั้งนี้ยังเน้นย้ำถึง calendar versioning ซึ่งสมาชิกชุมชนบางคนเรียกว่า Gregorian versioning ว่าเป็นทางเลือกที่ใช้งานได้จริงแทน semantic versioning แนวทางนี้ใช้วันที่ในหมายเลขเวอร์ชัน ทำให้ผู้ใช้ทราบได้ทันทีว่าซอฟต์แวร์ได้รับการอัปเดตครั้งสุดท้ายเมื่อไหร่ การกำหนดเวอร์ชันแพ็กเกจของ Ubuntu เป็นตัวอย่างของวิธีนี้ ช่วยให้ผู้ใช้สามารถระบุได้อย่างรวดเร็วว่าโปรเจกต์ยังคงได้รับการดูแลอย่างต่อเนื่องหรือถูกทิ้งร้างไปแล้ว
สิ่งนี้สมเหตุสมผลมากกว่าที่ดูเผินๆ semver เป็นเรื่องโกหกเพราะทุกการเปลี่ยนแปลงคือการเปลี่ยนแปลงที่ทำลาย
ความรู้สึกนี้สะท้อนถึงความสงสัยที่เพิ่มมากขึ้นเกี่ยวกับประสิทธิภาพของ semantic versioning ในการปฏิบัติจริง โดยอ้างอิงถึง Hyrum's Law - หลักการที่ว่าเมื่อมีผู้ใช้เพียงพอ พฤติกรรมที่สังเกตได้ทุกอย่างจะกลายเป็นส่วนหนึ่งของ API
กฎการกำหนดเวอร์ชัน Pride
- เวอร์ชัน PROUD: เพิ่มขึ้นเมื่อทำการเปลี่ยนแปลงที่คุณภูมิใจจริงๆ
- เวอร์ชัน DEFAULT: เพิ่มขึ้นสำหรับการปล่อยเวอร์ชันที่ธรรมดา
- เวอร์ชัน SHAME: เพิ่มขึ้นเมื่อแก้ไขบั๊กที่น่าอาย
- กฎการรีเซ็ต: เมื่อเพิ่มเวอร์ชัน PROUD ให้รีเซ็ตตัวเลขอื่นๆ เป็น 0 (เช่น 1.2.3 → 2.0.0)
- ส่วนเสริม: มีป้ายกำกับ pre-release และ build metadata
การตรวจสอบความเป็นจริงสำหรับความหมายของหมายเลขเวอร์ชัน
แม้ว่า Pride Versioning จะเริ่มต้นเป็นแนวคิดที่มีอารมณ์ขัน แต่ก็ได้รับการตอบรับจากนักพัฒนาที่เข้าใจความเป็นจริงทางอารมณ์เบื้องหลังการปล่อยซอฟต์แวร์ การพูดคุยของชุมชนเผยให้เห็นว่านักพัฒนาหลายคนจัดหมวดหมู่การปล่อยของตนเองอย่างไม่เป็นทางการตามระดับความมั่นใจมากกว่าผลกระทบทางเทคนิคเพียงอย่างเดียว นักพัฒนาบางคนสังเกตว่าควรเพิ่มตัวเลขเวอร์ชันการตลาดเป็นหมายเลขแรก เพื่อรับรองว่าข้อพิจารณาทางธุรกิจมักจะมีความสำคัญเหนือตรรกะการกำหนดเวอร์ชันทางเทคนิค
การสนทนาในที่สุดเน้นย้ำถึงความท้าทายที่ยังคงมีอยู่ในการสื่อสารการเปลี่ยนแปลงของซอฟต์แวร์ให้ผู้ใช้เข้าใจได้อย่างมีประสิทธิภาพ ในขณะที่ต้องสร้างสมดุลระหว่างความแม่นยำทางเทคนิคกับความต้องการในทางปฏิบัติ
อ้างอิง: Pride Versioning 0.3.0