คุณใช้“ แผนการตั้งชื่อเวอร์ชัน” อะไร [ปิด]

ข้อตกลงการตั้งชื่อเวอร์ชันต่างกันเหมาะสมกับโครงการที่แตกต่างกันหรือไม่ คุณใช้อะไรและทำไม

โดยส่วนตัวแล้วฉันชอบหมายเลขบิลด์เป็นเลขฐานสิบหก (เช่น 11BCF) ซึ่งควรเพิ่มขึ้นเป็นประจำ จากนั้นสำหรับลูกค้าจะมีหมายเลขเวอร์ชัน 3 หลักอย่างง่ายคือ 1.1.3

1.2.3 (11BCF) <- Build number, should correspond with a revision in source control
^ ^ ^
| | |
| | +--- Minor bugs, spelling mistakes, etc.
| +----- Minor features, major bug fixes, etc.
+------- Major version, UX changes, file format changes, etc.

ฉันพบตัวเองไม่ค่อยเห็นพ้องที่สมบูรณ์กับเจฟฟ์แอด แต่ฉันมักจะทำตามความเห็นของเขาการประชุม .NET ของรุ่นหมายเลข

(รุ่นใหญ่). (รุ่นรอง). (หมายเลขรุ่น). (หมายเลขรุ่น)

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

การกำหนดเวอร์ชันแบบ Semantic ( http://semver.org/ ) ควรกล่าวถึงที่นี่ [Major].[Minor].[Patch]มันเป็นสเปคของประชาชนสำหรับโครงการเวอร์ชันในรูปแบบของ แรงจูงใจสำหรับโครงร่างนี้คือการสื่อสารความหมายกับหมายเลขรุ่น

ฉันไม่ได้ใช้ แต่ฉันได้เห็นแล้วและมันเป็นโครงสร้างที่น่าสนใจ:

Year.Month.Day.Build

อธิบายตนเอง

ฉันพยายามใช้นโยบาย RubyGems Rational Versioningซึ่ง:

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

นี่เป็นวิธีที่ละเอียดมากในการกำหนดหมายเลขเวอร์ชัน:

• N.x.Kที่ไหนNและKเป็นจำนวนเต็ม 1.x.0ตัวอย่าง: 5.x.1, 10.x.33, ใช้สำหรับเป็นสื่อกลางสร้าง
• N.M.Kที่N, MและKเป็นจำนวนเต็ม 1.0.0ตัวอย่าง: 5.3.1, 10.22.33, ที่ใช้สำหรับการเผยแพร่
• N.x.xที่Nเป็นจำนวนเต็ม ตัวอย่าง: 1.x.x. ใช้สำหรับสาขาการสนับสนุน
• N.M.xที่ไหนNและMเป็นจำนวนเต็ม ตัวอย่าง: 1.0.x. ใช้สำหรับสาขาปล่อย

นี่คือรูปภาพสำหรับภาพประกอบอย่างง่ายของวิธีการกำหนดหมายเลขเวอร์ชัน:

PAหมายถึงpre-alpha A หมายถึงalpha B หมายถึงbeta ARหมายถึงalpha-release BRหมายถึงbeta-release RCหมายถึงrelease candidate STหมายถึงเสถียร

ข้อดีของวิธีการกำหนดหมายเลขเวอร์ชันดังต่อไปนี้:

• เพราะมันหมายถึงเฉพาะของวงจรการพัฒนาซอฟต์แวร์เปรียว
• มันต้องใช้เวลาเป็นข้อมูลเฉพาะบัญชีของแหล่งที่มาของโครงสร้างพื้นที่เก็บข้อมูลรหัส
• มันอธิบายตัวเองสำหรับผู้ที่คุ้นเคยกับรูปแบบ ทุกรูปแบบแสดงถึงสิ่งประดิษฐ์ที่แตกต่างกัน รูปแบบดังกล่าวสามารถแยกวิเคราะห์ได้ง่ายและใช้เพื่อวัตถุประสงค์อื่นเช่นการติดตามปัญหา
• เวอร์ชันรูปแบบตั้งซึ่งขั้นพื้นฐานสำหรับวิธีการอธิบายเวอร์ชันที่สามารถใช้สำหรับตัวชี้วัดการชุมนุมและการวางแผน
• จะมุ่งเน้นแนวคิดของการครบกําหนดและระดับของคุณภาพ บ่อยครั้งที่มีการกำหนดหมายเลขเวอร์ชันดังกล่าวเป็น 1.0.0 โดยไม่จำเป็นมาก (เมื่อซอฟต์แวร์อยู่ในระดับลึก) วิธีการกำหนดหมายเลขเวอร์ชันที่นำเสนอช่วยให้สามารถสร้างวุฒิภาวะได้หลายระดับ ในกรณีที่ง่ายที่สุดจะมีเพียงสองระดับเท่านั้น: build กลาง ( N.x.K) และปล่อย ( N.M.K) การเปิดตัวหมายถึงชิ้นส่วนของซอฟต์แวร์ที่มีหมายเลขเวอร์ชันเต็ม ( N.M.K) ได้ผ่านกระบวนการจัดการคุณภาพบางประเภทภายใน บริษัท ซัพพลายเออร์ / องค์กร / ทีม
• มันเป็นหลักฐานของลักษณะความคล่องตัวของการพัฒนาและการทดสอบ
• ส่งเสริมวิธีการแยกส่วนเพื่อโครงสร้างซอฟต์แวร์และสถาปัตยกรรม

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

โดยส่วนตัวแล้วทัศนคติของฉันที่มีต่อการใช้เวอร์ชันวันที่แทนที่จะเป็นตัวเลขเวอร์ชันจริงถือว่านักพัฒนาซอฟต์แวร์นั้นใช้เวอร์ชันวันที่:

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

วิธีนี้อาจดูขัดแย้งเล็กน้อย แต่ฉันเชื่อว่านี่เป็นวิธีที่ตรงไปตรงมาที่สุดในการให้หมายเลขเวอร์ชั่นของซอฟต์แวร์ที่เหมาะสม

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

[เงื่อนไขอ่อนแอ] [ชื่อสัตว์พยัญชนะ]

ซึ่งให้ชื่อเช่น " Limp Lamprey ", " Wombed Wombat " และ " Asthmatic Anteater "

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

Generation.Version.Revision.Build (9.99.999.9999)

การสร้างไม่ค่อยเปลี่ยนแปลง เฉพาะผลิตภัณฑ์ที่มีขนาดใหญ่เท่านั้น: DOS -> Windows, การปรับโครงสร้างระบบใหม่ให้สมบูรณ์

เวอร์ชันสำหรับการเปลี่ยนแปลงที่เข้ากันไม่ได้มากฟังก์ชั่นใหม่การเปลี่ยนแปลงในกระบวนทัศน์เฉพาะบางอย่างเกี่ยวกับซอฟต์แวร์ ฯลฯ

การแก้ไขมักจะทำ (คุณสมบัติเล็กน้อยและแก้ไขข้อบกพร่อง)

Build เป็นข้อมูลภายใน

git describeให้ส่วนขยายที่ดีสำหรับสิ่งที่คุณเลือก มันง่ายพอที่จะฝังในกระบวนการสร้าง / บรรจุภัณฑ์ / การปรับใช้ของคุณ

สมมติว่าคุณตั้งชื่อรุ่นวางจำหน่ายของคุณที่ติดแท็ก ABC (major.minor.maintenance) git describeบนคอมมิทที่กำหนดไว้จะพบบรรพบุรุษที่ติดแท็กล่าสุดของคอมมิชชัน, จากนั้นทำการเปลี่ยนแปลงจำนวนคอมมิชชันตั้งแต่นั้นมา, และตัวย่อ SHA1 ของคอมมิท

1.2.3-164-g6f10c

หากคุณเป็นหนึ่งในรุ่นที่แน่นอนคุณจะได้รับแท็ก (1.2.3)

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

Major.Minor.Public (build) [alpha / beta / Trial] เช่น "4.08c (1290)"

• ด้วย Major เป็นหมายเลขเวอร์ชันหลัก (1, 2, 3 ... )
• เล็กน้อยเป็นรุ่นรอง 2 หลัก (01, 02, 03 ... ) โดยทั่วไปแล้วเลขหลักสิบจะเพิ่มขึ้นเมื่อมีการเพิ่มฟังก์ชันการทำงานใหม่อย่างมีนัยสำคัญสำหรับการแก้ไขข้อบกพร่องเท่านั้น
• สาธารณะเป็นรุ่นสาธารณะของการสร้าง (a, b, c, d, e) ซึ่งมักจะแตกต่างจากรุ่นรองถ้ารุ่นรองไม่เคยถูกปล่อยออกมาเป็นการปรับปรุงสาธารณะ
• build เป็นหมายเลขบิลด์จริงที่คอมไพเลอร์คอยติดตาม
• พร้อม TRIAL, ALPHA, BETA X หรือ RC X ต่อท้ายสำหรับกรณีพิเศษเหล่านั้น

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

ฉันใช้. NET ดังนั้นฉันจึงติดอยู่กับระบบการกำหนดหมายเลข. NET แต่ฉันพยายามให้ความหมายทางความหมายกับตัวเลขเช่นนั้น

major.minor.build.revision

• สำคัญ = (สูงสุดโครงการ)
• เล็กน้อย = (สูงสุดโครงการ)
• build = หมายเลขบิวด์จากฮัดสัน (คุณสามารถใช้ TeamCity หรือ TeamBuild ฯลฯ ที่นี่)
• revision = การโค่นล้มหรือการแก้ไขตลาดสด (ขึ้นอยู่กับโครงการและการใช้งาน)

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

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

มันคือทั้งหมดที่เกี่ยวกับการตรวจสอบย้อนกลับ!

เราใช้Major.Minor.Build # .YYMMDD [คำต่อท้าย] เนื่องจากเรามักจะสร้างหนึ่งการผลิตในวันใดวันหนึ่ง (แต่ใช้ ab / c / d ต่อท้ายหากมีมากกว่าหนึ่ง) และ YYMMDD ให้ผู้ใช้ / ลูกค้า / การจัดการ ข้อบ่งชี้อายุของบิลด์ที่ 6.3.1389 ไม่

ตัวเลขหลักเพิ่มขึ้นพร้อมคุณสมบัติของผลิตภัณฑ์ที่สำคัญ (ชำระเงิน)

ตัวเลขเพิ่มขึ้นเล็กน้อยด้วยการแก้ไข / ปรับปรุง (อัปเดตฟรี)

สร้างเพิ่มขึ้นเสมอ ไม่ได้สร้างเรือทั้งหมดดังนั้นจึงไม่ใช่ความก้าวหน้าเชิงเส้น

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

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

ฉันชอบเวอร์ชั่นที่ใช้ความหมาย :

• Majorประชาสัมพันธ์ Minor.Patch
• Patch เพิ่มขึ้นทุกครั้งที่คุณปล่อยบิลด์
• Minor เพิ่มทุกครั้งที่มีการเพิ่มฟังก์ชั่นที่ใช้งานร่วมกันได้
• Major เพิ่มขึ้นเมื่อฟังก์ชั่นใหม่ไม่รองรับการทำงานย้อนหลัง
• เมื่อMajor== 0 คุณอยู่ในอัลฟ่า / ก่อนเผยแพร่ Major> = 1 เป็นรุ่นสาธารณะของคุณ
• ตัวเลขที่ต่ำกว่าจะรีเซ็ตเป็น 0 ทุกครั้งที่คุณเพิ่มขึ้นดังนั้น

  1.5.3-> 1.5.4(แก้ไขข้อผิดพลาด) -> 1.6.0(คุณสมบัติย่อย) -> 2.0.0(การแตกหักการเปลี่ยนแปลง)

              1.0.0
                |
              1.0.1
                |
(สาธารณะ 1.0) 1.0.2 -----
                | \
              2.0.0 1.1.0
                | |
              2.0.1 1.1.1 (สาธารณะ 1.1)
                |
(สาธารณะ 2.0) 2.0.2 -----
                | \
              3.0.0 2.1.0
                         |
                       2.1.1 (สาธารณะ 2.1)
                         |
                       2.2.0
                         |
                       2.2.1

X.Y.Zคือหมายเลขเวอร์ชันภายในของเรา X.Yเป็นหมายเลขรุ่นสาธารณะหมายเลขที่มีความหมายกับลูกค้าของเรา เมื่อX.Y.Zรุ่นกลายเป็นรุ่นสาธารณะจะไม่มีX.Y.(Z+1)รุ่น: รุ่นสาธารณะจะเป็นรุ่นสุดท้ายเสมอ

X จะเพิ่มขึ้นเมื่อมีการเปิดตัวรุ่นใหญ่

Y ใช้สำหรับสาขาการบำรุงรักษาของรีลีสหลักเหล่านั้นสำหรับการแก้ไขบั๊กเท่านั้น

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

ในฐานะที่เป็นบันทึกด้านข้างเราใช้ maven (พร้อมreleaseคำสั่ง) เพื่อเพิ่มหมายเลขรุ่น ดังนั้นจึงมีX.Y.Z-SNAPSHOTรุ่นด้วยเช่นกัน (ซึ่งระบุรุ่นใดก็ได้ระหว่างX.Y.(Z-1)และX.Y.Z)