การกำหนดเวอร์ชันแบบ Semantic อนุญาตให้มี 4 คอมโพเนนต์ในหมายเลขเวอร์ชันหรือไม่

ตัวอย่างทั้งหมดของการกำหนดเวอร์ชันทางความหมายที่ฉันเห็นแสดงส่วนประกอบที่ใช้งานอยู่ 3 รายการ ไม่เกิน 2 จุดอักขระ ที่$DAYJOBเราใช้ 4 องค์ประกอบในหมายเลขรุ่นของเรา:

5.0.1.2

การกำหนดเวอร์ชันแบบ Semantic อนุญาตสำหรับสิ่งนี้หรือไม่

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

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

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

สิ่งที่คุณกำลังทำคือการสร้างหมายเลขรุ่นพิเศษ (หลัก PCI รองของคุณ) อย่างมีประสิทธิภาพเพื่อย้ายคุณลักษณะ / หมายเลขรุ่นรองกลับไปที่เดิมเพื่อไม่ให้เกิดเกณฑ์การตรวจสอบภายในของคุณอีกต่อไป

ยังไงก็ตามขอให้คุณตั้งคำถามเกี่ยวกับการกำหนดเวอร์ชัน semantic, ข้อมูลจำเพาะสำหรับ Semantic Versioning states:

รับหมายเลขเวอร์ชัน MAJOR.MINOR.PATCH เพิ่มค่า:

• รุ่น MAJOR เมื่อคุณทำการเปลี่ยนแปลง API ที่เข้ากันไม่ได้
• รุ่นรองเมื่อคุณเพิ่มฟังก์ชันการทำงานในลักษณะที่เข้ากันได้ย้อนหลังและ
• รุ่น PATCH เมื่อคุณทำการแก้ไขข้อบกพร่องที่เข้ากันได้ย้อนหลัง
• ฉลากเพิ่มเติมสำหรับรุ่นก่อนวางจำหน่ายและการสร้างเมตาดาต้าที่มีอยู่เป็นส่วนขยายไปยังรูปแบบ MAJOR.MINOR.PATCH

เน้นการขุด

ดังนั้นคำถามคือคุณใช้อักขระตัวที่สี่สำหรับข้อมูลเมตา pre-release / build หรือไม่ หรือว่าเป็นอีกรุ่นหนึ่งที่บ่งบอกว่าคุณกำลังปล่อยออกมา?

หาก "ใช่" สเปคของการกำหนดเวอร์ชันแบบ semantic จะอนุญาต หาก "ไม่ใช่" คุณจะไม่ติดตามเวอร์ชันเชิงความหมายในทางเทคนิค

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

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

การแก้ไขข้อบกพร่องไม่ส่งผลกระทบต่อ API ที่เพิ่มขึ้นของเวอร์ชันแพตช์, การเพิ่ม / เปลี่ยน API ที่เข้ากันได้แบบย้อนหลังนั้นเป็นการเพิ่มรุ่นรอง, และการเปลี่ยนแปลง API ที่เข้ากันไม่ได้ย้อนหลังเป็นการเพิ่มรุ่นหลัก

ฉันเรียกระบบนี้ว่า "Semantic Versioning" ภายใต้โครงร่างนี้หมายเลขรุ่นและวิธีที่พวกเขาเปลี่ยนสื่อความหมายเกี่ยวกับรหัสอ้างอิงและสิ่งที่ได้รับการแก้ไขจากรุ่นหนึ่งเป็นรุ่นถัดไป

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

ตราบใดที่ API ของคุณมีความชัดเจนในทำนองเดียวกันก็ไม่ใช่เรื่องใหญ่ในแบบที่คุณเลือก การกำหนดเวอร์ชันความหมายเกิดขึ้นตรงไปตรงมาเช่นถ้าฉันใช้ 3.4.2 และจำเป็นต้องอัปเกรดเป็น 3.4.10 ฉันรู้ว่าฉันสามารถทำได้โดยไม่ทำลายอะไรเลย หากเวอร์ชันใหม่คือ 3.5.1 ฉันรู้ว่ามันเข้ากันได้ย้อนหลัง และฉันรู้ว่ารุ่น 4.0.1 จะเป็นการเปลี่ยนแปลงที่ไม่ดี

นั่นเป็นส่วนหนึ่งของความหมายของหมายเลขรุ่นทั้งหมด

@enderland ใช่โดยทั่วไป MAJOR (PCI) .MINOR (PCI) .FEATURE.HOTFIX + BUILD โดยพื้นฐานแล้วเราได้รับอนุญาตให้เปลี่ยนองค์ประกอบที่ 3 และ 4 โดยไม่ต้องมี PCI (และต่อมา PCI ทับซ้อนที่ บริษัท ) ที่เกี่ยวข้อง สำหรับฉันแล้วรู้สึกว่านี่เป็นสิ่งที่ถูกประดิษฐ์ขึ้นมาเล็กน้อยฉันไม่แน่ใจว่าพวกเขาได้รับความชอบธรรมในวิธีที่พวกเขาจัดการหมายเลขรุ่น แต่ฉันไม่รู้เพียงพอเกี่ยวกับ PCI และกระบวนการตรวจสอบที่จะพูดเป็นอย่างอื่น

ตกลงนี่เป็นเรื่องปกติ คุณมีระบบที่เหมาะกับคุณและตรงตามความต้องการของคุณ นั่นคือประเด็นของการกำหนดเวอร์ชัน

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

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

ในเวอร์ชันปัจจุบันของ Semantic Versioning ซึ่งเป็น 2.0.0ไม่ใช่ มีข้อกำหนดที่กำหนดเวอร์ชันเป็นรูปแบบ XYZ โดยที่ X, Y และ Z เป็นจำนวนเต็มแบบไม่ลบที่ไม่มีการนำ 0s:

หมายเลขเวอร์ชันปกติต้องอยู่ในรูปแบบ XYZ โดยที่ X, Y และ Z เป็นจำนวนเต็มไม่เป็นลบและต้องไม่มีเลขศูนย์นำหน้า X เป็นรุ่นหลัก Y เป็นรุ่นรองและ Z เป็นรุ่นปรับปรุง แต่ละองค์ประกอบจะต้องเพิ่มตัวเลข ตัวอย่างเช่น: 1.9.0 -> 1.10.0 -> 1.11.0

อย่างไรก็ตามความสามารถในการเพิ่มข้อมูลเมตาได้รับอนุญาตสำหรับ:

Build metadata MAY สามารถแสดงได้โดยผนวกเครื่องหมายบวกและชุดของตัวระบุจุดที่คั่นด้วยจุดต่อจากแพทช์หรือเวอร์ชั่นก่อนวางจำหน่าย ตัวระบุต้องประกอบด้วยตัวอักษรและตัวเลข ASCII เท่านั้น [0-9A-Za-z-] ตัวระบุต้องไม่เว้นว่าง Build metadata SHOULD จะถูกละเว้นเมื่อพิจารณาถึงความสำคัญของเวอร์ชัน ดังนั้นสองเวอร์ชันที่แตกต่างกันเฉพาะในข้อมูลเมตาของบิลด์มีความสำคัญเท่ากัน ตัวอย่าง: 1.0.0-alpha + 001, 1.0.0 + 20130313144700, 1.0.0-beta + exp.sha.5114f85

อย่างไรก็ตามสิ่งสำคัญที่ควรทราบคือการกำหนดเวอร์ชันแบบความหมายสำหรับซอฟต์แวร์ที่ประกาศ API สาธารณะ:

ซอฟต์แวร์ที่ใช้ Semantic Versioning ต้องประกาศ API สาธารณะ API นี้สามารถประกาศในโค้ดเองหรือมีอยู่จริงในเอกสารประกอบ อย่างไรก็ตามมันจะทำมันควรจะแม่นยำและครอบคลุม

สิ่งนี้มีแนวโน้มที่จะสนับสนุนการพัฒนาไลบรารีหรือบริการและไม่ใช่ระดับแอปพลิเคชัน

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