หมายเลขเวอร์ชั่นก่อนหน้าทำงานอย่างไรสำหรับผลิตภัณฑ์ใหม่

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

การวิจัยของฉันทำให้เกิดผลลัพธ์ที่เกี่ยวข้องเหล่านี้

• คุณใช้ "แผนการตั้งชื่อเวอร์ชัน" อะไร
• คุณทำเวอร์ชันไฟล์อย่างไร (หมายเลขเวอร์ชัน)
• โครงการแยกที่หมายเลขเวอร์ชันของฉันเริ่มต้นที่ไหน

แต่ไม่มีพวกเขาที่ระบุหมายเลขของอัลฟ่า, เบตา, ผู้สมัครอิสระ, & c ข้อตกลงสำหรับหมายเลขรุ่นต่ำกว่า 1.0 คืออะไร ฉันรู้ว่าพวกเขาสามารถไปบางครั้ง; ตัวอย่างเช่น PuTTY มีมานานอย่างน้อยหนึ่งทศวรรษและยังคงเป็นรุ่นเบต้า 0.60 เท่านั้น

มันขึ้นอยู่กับโครงการ บางโครงการไม่ปล่อยรุ่น 1.0 ด้วยซ้ำ

นักพัฒนาของ MAME ไม่ได้ตั้งใจที่จะปล่อยโปรแกรมจำลองรุ่น 1.0 ข้อโต้แย้งคือมันจะไม่ "เสร็จสิ้น" อย่างแท้จริงเพราะจะมีเกมอาร์เคดมากขึ้นเสมอ เวอร์ชัน 0.99 นั้นตามมาด้วยเวอร์ชัน 0.100 (รุ่นรอง 100> 99) ในแฟชั่นที่คล้ายกัน Xfire 1.99 มีผู้ติดตาม 1.100 หลังจาก 6 ปีของการพัฒนา eMule ยังไม่ถึงเวอร์ชัน 0.50 ^{ซอฟต์แวร์เวอร์ชันที่ Wikipedia}

หนึ่งในวิธีที่นิยมใช้เลขรุ่น (ที่ผมได้เริ่มต้นที่จะใช้) เป็นความหมายของรุ่น

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

คำพูดบางคำเสนอแนวคิดเพิ่มเติมเกี่ยวกับวิธีการทำงานและ / หรือตอบคำถามของคุณ:

ฉันจะรู้ได้อย่างไรว่าจะปล่อย 1.0.0 เมื่อไหร่?

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

สิ่งนี้ไม่ทำให้เกิดการพัฒนาอย่างรวดเร็วและการวนซ้ำอย่างรวดเร็วหรือไม่

รุ่นใหญ่ศูนย์คือทั้งหมดที่เกี่ยวกับการพัฒนาอย่างรวดเร็ว หากคุณเปลี่ยน API ทุกวันคุณควรอยู่ในเวอร์ชัน 0.xx หรือสาขาการพัฒนาแยกต่างหากซึ่งทำงานในเวอร์ชันหลักถัดไป

หากการเปลี่ยนแปลงที่เข้ากันไม่ได้น้อยที่สุดไปสู่ ​​API สาธารณะต้องมีการชนรุ่นใหญ่ฉันจะไม่ลงเอยที่รุ่น 42.0.0 อย่างรวดเร็วหรือไม่

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

นอกจากนี้ยังมีกฎว่าด้วยการระบุรุ่น "alpha," "beta," ฯลฯ ตรวจสอบรายละเอียดที่http://semver.org/

[แก้ไข] โครงร่างการกำหนดหมายเลขรุ่นที่น่าสนใจอีกอย่างหนึ่งคือMongoDB ที่ใช้ :

MongoDB ใช้รุ่นเลขคี่สำหรับการพัฒนารุ่น

มีตัวเลข 3 ตัวในเวอร์ชั่น MongoDB: ABC

• A เป็นเวอร์ชันหลัก สิ่งนี้จะไม่ค่อยเปลี่ยนแปลงและบ่งบอกถึงการเปลี่ยนแปลงครั้งใหญ่มาก
• B คือหมายเลขรุ่น ซึ่งจะรวมถึงการเปลี่ยนแปลงจำนวนมากรวมถึงคุณสมบัติและสิ่งต่าง ๆ ที่อาจทำลายความเข้ากันได้ย้อนหลัง แม้แต่ Bs จะเป็นกิ่งที่มีเสถียรภาพและ Bs แปลก ๆ ก็คือการพัฒนา
• C คือหมายเลขการแก้ไขและจะใช้สำหรับข้อบกพร่องและปัญหาด้านความปลอดภัย

ตัวอย่างเช่น:

• 1.0.0: GA รุ่นแรก
• 1.0.x: แก้ไขข้อบกพร่องเป็น 1.0.x - ขอแนะนำให้อัปเกรดมีความเสี่ยงน้อยมาก
• 1.1.x: การเปิดตัวการพัฒนา ซึ่งจะรวมถึงคุณสมบัติใหม่ที่ยังไม่เสร็จสมบูรณ์และอยู่ระหว่างดำเนินการ บางสิ่งอาจแตกต่างจาก 1.0
• 1.2.x: การเปิดตัว GA ครั้งที่สอง นี่จะเป็นสุดยอดของการเปิดตัว 1.1.x

ฉันไม่คิดว่าจะมี "มาตรฐาน" เช่นนี้

มีข้อตกลงสำหรับผู้สมัครรับการปล่อยตัวซึ่งมักจะเป็น "[เวอร์ชั่น] RC 1" ฯลฯ ขึ้นอยู่กับว่าคุณคิดว่าจะปล่อยรุ่นใดบ้าง

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

ฉันจะใช้ "Alpha" และ "Beta" เช่น Release Candidate - สำหรับรุ่นที่มีเวลา จำกัด เพื่อระบุว่าคุณคิดว่าคุณใกล้จะเปิดตัวเวอร์ชั่นเต็มแล้ว

มีหน้าวิกิพีเดียเป็นซอฟแวร์รุ่น สำหรับการแบ่งปันเวอร์ชันก่อน 1.0 การประชุมที่ Apple ใช้และอื่น ๆ นั้นใช้งานได้ดี: major.minor.maintSrev โดยที่ S เป็นตัวบ่งชี้ระยะสำหรับรุ่นก่อนวางจำหน่าย: d = การพัฒนา a = alpha, b = beta, rc = ตัวเลือกการเปิดตัว ดังนั้นเวอร์ชันภายในแรกของคุณอาจเป็น 1.0.0d1

สำหรับการแก้ไขภายในอย่างสมบูรณ์การประทับเวลาก็เพียงพอแล้ว

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

อย่างที่คนอื่นพูดกันแล้วดูเหมือนจะไม่ได้มาตรฐานที่แน่นอน องค์กรของเราใช้สัญลักษณ์ต่อไปนี้:

รุ่น 1.0 ---> 2.0 (เพิ่มคุณสมบัติใหม่ / ปรับปรุงที่สำคัญลงในผลิตภัณฑ์)

การเปิดตัว 1.0 ---> 1.1 (มีการเพิ่มคุณสมบัติใหม่ / ปรับปรุงระดับกลางลงในผลิตภัณฑ์)

รุ่น 1.0 ---> 1.001 (แก้ไขข้อผิดพลาด)

เหตุการณ์สำคัญ "เวอร์ชั่น 1.0" มีความสำคัญอย่างยิ่งต่อผู้ใช้คอมพิวเตอร์ที่มีประสบการณ์เพราะมันหมายถึงว่าโปรแกรมเสร็จสิ้นและทำงานได้ตามที่คาดหวัง สิ่งใดในรุ่น "0.something" หมายความว่าโปรแกรมเมอร์ที่ตัวเองคิดว่าโปรแกรมจะไม่ได้ทำเลย

คุณสามารถเก็บหมายเลขเวอร์ชัน "0.1", "0.2" ... สำหรับความสำเร็จที่สำคัญของฟังก์ชันการทำงานและจากนั้นเซ็ตย่อยด้วยหมายเลขบิลด์ซึ่งบ่อยครั้งเป็นวันที่และการประทับเวลาที่ดี