กำลังมองหาแนวปฏิบัติที่ดีที่สุดสำหรับการกำหนดหมายเลขเวอร์ชันของส่วนประกอบซอฟต์แวร์ที่ต้องพึ่งพา

เรากำลังพยายามตัดสินใจเกี่ยวกับวิธีการกำหนดหมายเลขรุ่นสำหรับส่วนประกอบซอฟต์แวร์ที่ดีซึ่งขึ้นอยู่กับซึ่งกันและกัน

ให้เจาะจงยิ่งขึ้น:

องค์ประกอบซอฟต์แวร์ A เป็นเฟิร์มแวร์ที่ทำงานอยู่บนอุปกรณ์ฝังตัวและส่วนประกอบ B เป็นไดรเวอร์ที่เกี่ยวข้องสำหรับพีซีปกติ (เครื่อง Linux / Windows) พวกเขากำลังสื่อสารกันโดยใช้โปรโตคอลที่กำหนดเอง เนื่องจากผลิตภัณฑ์ของเรามีการกำหนดเป้าหมายที่นักพัฒนาเราจะเสนอทั้งสองเวอร์ชันที่เสถียรและไม่เสถียร (ทดลอง) ของส่วนประกอบทั้งสอง (เฟิร์มแวร์เป็นแบบโอเพ่นซอร์สในขณะที่ไดรเวอร์เป็นโอเพ่นซอร์ส) ปัญหาที่ใหญ่ที่สุดของเราคือวิธีจัดการกับการเปลี่ยนแปลง API ในโปรโตคอลการสื่อสาร

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

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

ดังนั้นนี่คือทางออกของเรา:

เราวางแผนที่จะติดตามหมายเลขรุ่นmajor.minor.patch ที่ใช้กันอย่างแพร่หลายและใช้เลขคู่รอง / คู่สำหรับรุ่นเสถียร / ไม่เสถียร หากเราแนะนำการเปลี่ยนแปลงใน API เราจะเพิ่มจำนวนรองลงมา

การประชุมนี้จะนำไปสู่สถานการณ์ตัวอย่างต่อไปนี้:

สาขาที่มั่นคงในปัจจุบันคือ 1.2.1 และไม่เสถียรคือ 1.3.7 ตอนนี้แพทช์ใหม่สำหรับการเปลี่ยนแปลงที่ไม่เสถียรของ API สิ่งที่จะทำให้หมายเลขรุ่นที่ไม่เสถียรใหม่กลายเป็น 1.5.0 ครั้งหนึ่งสาขาที่ไม่เสถียรถือว่าเสถียรแล้วสมมุติใน 1.5.3 เราจะปล่อยมันเป็น 1.4.0

ฉันยินดีที่จะตอบคำถามใด ๆ ที่เกี่ยวข้องด้านล่าง:

• คุณช่วยแนะนำวิธีปฏิบัติที่ดีที่สุดสำหรับการจัดการปัญหาที่อธิบายไว้ข้างต้นได้หรือไม่?
• คุณคิดว่าการประชุม "กำหนดเอง" ของเราดีหรือไม่?
• คุณต้องการเปลี่ยนแปลงอะไรบ้างกับการประชุมที่อธิบายไว้?

หมายเลขรุ่น IMHO เหมือนชื่อผลิตภัณฑ์ สำคัญในสิ่งที่มองเห็นได้ แต่ไม่สำคัญในการตกแต่งมากกว่าเนื้อหา

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

หมายเลขเวอร์ชันกำลังเพิ่มขึ้นอย่างน่าเบื่อ
นี่อาจเป็นความคาดหวังที่ชัดเจนที่สุดและในเวลาเดียวกัน ผู้ใช้คาดหวังว่าเวอร์ชั่น 2.3.5 จะมาหลังจากเวอร์ชั่น 2.2.17 และมีเทคโนโลยีเดียวกันหรือดีกว่า แต่แน่นอนว่า 2.3.x เป็นสาขาการพัฒนาและ 2.2.x มีเสถียรภาพและ 2.3.5 ได้เปิดตัวจริงในปี 2004 และ 2.2 สาขายังคงทำงานอย่างแข็งขันและ 2.2.17 เปิดตัวเมื่อเดือนเมษายนที่ผ่านมาและมี .. ดีคุณจะได้รับความคิด คุณอาจจะเรียก "Potato" เวอร์ชั่น 2.2 สำหรับความหมายทั้งหมดที่มี ยินดีต้อนรับสู่เวอร์ชั่น " Potato-17 " !!

รุ่นที่คล้ายกันสามารถ
อัปเกรด/ ใช้งานร่วมกันได้ถ้าฉันมีรุ่น 3.7 บนคอมพิวเตอร์ของฉันและ 3.8 มาพร้อมกับ frozbots ใหม่ทั้งหมดฉันคาดหวังว่าด้วยการอัพเกรดหรือแพทช์หรืออะไรก็ตาม 3.7 ของฉันจะกลายเป็น 3.8 โดยไม่มีการหยุดชะงัก แต่ถ้าฉันใช้ 3.7 และคุณปล่อย 5.2 ฉันก็ไม่ได้มองโลกในแง่ดีนัก แน่นอนว่าฉันต้องประหลาดใจมากกว่าผิดหวัง

ตัวเลขตัวแรกมีความสำคัญ
ฉันไม่ต้องกังวลที่จะพูดถึงเรื่องนี้หาก Java ไม่ได้สับสนอย่างชัดเจนในเรื่องนี้ คุณจะไม่คาดหวังว่า "Java 7" นั้นเป็นรุ่น 1.7 และเป็นครั้งแรกที่คุณเคยได้ยินนี้คุณตอบสนองก็เกือบจะแน่นอน: " อะไร .. ทำไม? "

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

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

- แก้ไข -
ฉันลืมที่จะพูดถึงเรื่องนี้ แต่Calebชี้ให้เห็นอย่างชัดเจน: อย่าใช้หมายเลขรุ่นเพื่อระบุสิ่งที่สำคัญ (เช่นเสถียร / ไม่เสถียร) โดยไม่ทำให้ชัดเจนที่อื่น ใช่คุณรู้ว่าหมายเลขรุ่นรองแปลก ๆ บ่งบอกถึงการพัฒนา แต่นั่นทำให้เราเป็นหนึ่งในนั้น ตัวอย่างการปล่อยชื่อ "ไม่เสถียร" ของเดเบียนเป็นตัวอย่างที่ดี หรือคุณอาจใช้ชื่อผลิตภัณฑ์แยกกันโดยสิ้นเชิง "Frozbot 1.2" สำหรับชื่อผลิตภัณฑ์ของคุณและ "Devbot 1.3" สำหรับเวอร์ชันการพัฒนาของคุณ

ครั้งหนึ่งสาขาที่ไม่เสถียรถือว่าเสถียรแล้วสมมุติใน 1.5.3 เราจะปล่อยมันเป็น 1.4.0

ไม่ไม่. สำหรับเสถียร 1.5.3 ที่ไม่เสถียรต้องเริ่มจาก 1.6.0 (และ 1.4.x เพิ่งพลาดไปถ้าคุณต้องการใช้ Semantic Versioning)

คุณกำลังพยายามใช้ค่าเดียวเพื่อระบุสองสิ่งที่แยกกัน

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

ประการที่สองคุณพยายามระบุว่ารุ่นที่กำหนดมีความเสถียรหรือไม่

เป็นไปได้ที่จะระบุทั้งสองสิ่งด้วย "หมายเลขรุ่น" เช่นเดียวกับที่ร้านค้าบางแห่งจะใช้รูปแบบการกำหนดราคาบางอย่างเพื่อระบุว่ารายการนั้นวางขายหรือไม่ ตัวอย่างเช่นราคาที่ลงท้ายด้วย '3' ที่ร้านใกล้ฉันคือราคาขายขั้นสุดท้าย ซึ่งทำงานได้ดีสำหรับพนักงานที่เรียนรู้วิธีการกำหนดราคาขายอย่างรวดเร็ว แต่ไม่ใช่วิธีที่ดีในการบอกลูกค้าเกี่ยวกับการขาย ด้วยเหตุนี้พวกเขาจึงติดป้ายใกล้กับสินค้าที่ขาย คุณสามารถทำสิ่งที่คล้ายกันได้เช่นการทำให้ตัวเลขที่สำคัญน้อยที่สุดสำหรับการปล่อยที่เสถียรและสม่ำเสมอและทำให้มันแปลกสำหรับการทดลองเชิงทดลอง แม้ว่าฉันคิดว่าถ้าคุณกำลังจะปล่อยบางอย่างที่กำลังทดสอบคุณควรทำเครื่องหมายอย่างชัดเจน คุณสามารถเพิ่ม 'X' ที่จุดเริ่มต้นหรือจุดสิ้นสุดของสตริงรุ่นเช่น:X.1.5.31.5.3.X. คุณสามารถแม้กระทั่งหมายเลขรุ่นทดลองหลังจากนั้นเพื่อให้คุณสามารถปล่อยรุ่นทดลองหลาย ๆ 1.5.3.X1ทั้งหมดขึ้นอยู่กับรุ่นฐานเดียวกัน1.5.3.X2,

นอกจากนี้คุณยังควรพิจารณาว่ามีความยาวประเพณีของการใช้ "อัลฟา" และ "เบต้า" หมายเลขรุ่น1.5.3a54เพื่อระบุรุ่นที่ไม่อาจจะทรงตัวหรือสมบูรณ์: ตรวจสอบให้แน่ใจว่าคุณมีเหตุผลที่ดีในการออกจากโครงการนี้หากคุณตัดสินใจที่จะทำสิ่งใดเพราะคุณอาจจะต้องอธิบายสิ่งอื่นใดกับชุมชนนักพัฒนาของคุณ

ฉันขอแนะนำให้ใช้รูปแบบ major.minor.patch โดยใช้ส่วนขยาย "แท็ก" สำหรับเวอร์ชันที่เสถียร / ไม่เสถียรและความหมายที่แน่นอนของตัวเลขหลักและรอง:

major.minor.patch-stable|unstable

ที่ไหน

major  only changes if there are incompatible changes in the API
minor  changes if there are changes in the API but backward compatibility is given
patch  any other changes, could be the build number or any other increasing number
-stable indicates the stable version
-unstable indicates the unstable version

วิธีนี้ขึ้นอยู่กับการจัดการได้อย่างง่ายดายและจะบอกลูกค้าแต่ละองค์ประกอบ / ผู้ใช้เมื่อพวกเขาต้องให้ความสำคัญกับรุ่นใหม่ เช่นถ้าส่วนประกอบ A (1.1.0-เสถียร) ขึ้นอยู่กับ B (5.4.534-stable) และเวอร์ชันใหม่ของ B ถึงกำหนด (6.1.0-เสถียร) หนึ่งทราบทันทีว่า A จะต้องมีการเปลี่ยนแปลงอาจเป็นไปได้อย่างมาก .

ฉันชอบวิธีการจำศีลของ Rhinos ที่ได้สร้าง RavenDb vis-a-vis เวอร์ชั่นขึ้นมา - พวกเขามีจำนวนบิลด์เพิ่มขึ้นเรื่อย ๆ เมื่อพวกเขาได้รับหนึ่งคงที่มันจะถูกทำเครื่องหมายที่มั่นคง แต่ทุกอย่างเป็นผู้สมัคร