แนวปฏิบัติที่ดีที่สุด: การกำหนดเวอร์ชันซอฟต์แวร์ [ปิด]


211

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

แต่ฉันจะเริ่มเวอร์ชันได้ที่ไหน 0.0.0? หรือ 0.0 แล้วฉันจะเพิ่มตัวเลขได้อย่างไร? รุ่นใหญ่การเปลี่ยนแปลงเล็กน้อย และไม่ควรมีข้อผูกมัดใด ๆ ต่อระบบควบคุมเวอร์ชันเป็นอีกเวอร์ชั่นหนึ่ง? หรือเป็นเพียงรุ่นที่ใช้ในการผลิตหรือไม่


2
เครื่องมือควบคุมซอร์สโค้ดของคุณทำอะไร คุณต้องใช้อย่างใดอย่างหนึ่ง คุณใช้อันไหน
S.Lott

3
ฉันเล็ก ๆ น้อย ๆ ... แต่ปลายล่อของstackoverflow.com/questions/615227/how-to-do-version-numbers
รากศัพท์


1
@DaveGregory มีคำตอบที่ไม่ใช่ความเห็นตามคำถาม ลิงค์semver.org นั้นจะอธิบายความหมายของการกำหนดเวอร์ชันในรายละเอียด ชุดรูปแบบเดียวกันนี้มักใช้โดยโครงการ Google ส่วนใหญ่รวมถึง Android ยิ่งไปกว่านั้นใน Tom Preston-Werner เราสามารถค้นหาเสียงที่น่าเชื่อถือได้ในหัวข้อนี้
ราหุล

คำตอบ:


125

คุณควรเริ่มต้นด้วยรุ่น 1 ยกเว้นว่าคุณรู้ว่ารุ่นแรกที่คุณ "วางจำหน่าย" ไม่สมบูรณ์ในบางวิธี

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

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

ดังนั้นหากคุณทำการเปลี่ยนแปลงที่สำคัญย้ายจากรุ่น 1.0.0.0 เป็นรุ่น 2.0.0.0 (คุณเปลี่ยนจาก WinForms เป็น WPF เป็นต้น) หากคุณทำการเปลี่ยนแปลงเล็ก ๆ เปลี่ยนจาก 1.0.0.0 เป็น 1.1.0.0 (คุณเพิ่มการรองรับไฟล์ png) หากคุณทำการเปลี่ยนแปลงเล็กน้อยแล้วไปจาก 1.0.0.0 เป็น 1.0.1.0 (คุณแก้ไขข้อบกพร่องบางอย่าง)

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


ฉันมีคำถามเกี่ยวกับคำตอบของคุณ: ถ้าฉันทำงานกับเวอร์ชัน 1.0.0.0 และฉันกำลังทำการเปลี่ยนแปลงเล็กน้อย, เล็กหรือใหญ่และฉันต้องการใช้หมายเลขบิลด์ ฉันต้องเพิ่มหมายเลขเวอร์ชันรุ่นใด ลองนึกภาพฉันย้ายจาก 1.0.0.0 เป็น 1.0.1.0 ฉันต้องใส่หมายเลขบิลด์หมายเลขใด และในรุ่นสุดท้ายนั้นจะมีการสร้างหมายเลขในหมายเลขเวอร์ชั่น (1.0.1.234) ด้วยหรือไม่
VansFannel

@VansFannel ฉันคาดว่าหมายเลขบิลด์จะรีเซ็ตเป็น 0 ทุกครั้งที่คุณชนหมายเลขที่สูงขึ้น
Jeffrey Kemp

@JeffreyKemp ใช่ฉันคิดอย่างนั้น แต่ที่ทำงานเราใช้จำนวนวันของปีและฉันไม่ชอบ
VansFannel

Yuck ฉันไม่ชอบมันเช่นกัน :(
Jeffrey Kemp

2
ควรสังเกตว่าการเปลี่ยนแปลงในรุ่นใหญ่มักจะไม่เข้ากันได้ย้อนหลัง การเพิ่มขึ้นของรุ่นรองจะเข้ากันได้แบบย้อนหลังภายในรุ่นหลัก การเปลี่ยนจากการติดตั้ง MySQL แบบรหัสตายตัวไปสู่การใช้งานทั่วไปอาจเป็นรุ่นใหญ่เนื่องจากขนาดของการเปลี่ยนแปลง แต่อาจพิจารณาการเปลี่ยนแปลงคุณสมบัติ (เล็กน้อย) เพราะมันยังเข้ากันได้ย้อนหลัง
DHW


42

ฉันทำตามรูปแบบนี้โดยทั่วไป:

  • เริ่มต้นจาก 0.1.0

  • เมื่อฉันพร้อมที่จะแยกรหัสใน repo ต้นทางให้แท็ก 0.1.0 และสร้างสาขา 0.1.0 ส่วนหัว / ลำตัวจะกลายเป็น 0.2.0-snapshot หรืออะไรที่คล้ายกัน

  • ฉันเพิ่มคุณสมบัติใหม่ให้กับ trunk เท่านั้น แต่ backport Fix ให้กับสาขาและในเวลาที่ฉันปล่อยจากมัน 0.1.1, 0.1.2, ...

  • ฉันประกาศเวอร์ชัน 1.0.0 เมื่อผลิตภัณฑ์ถูกพิจารณาว่าสมบูรณ์และไม่มีข้อบกพร่องที่สำคัญ

  • จากนั้น - ทุกคนสามารถตัดสินใจได้ว่าจะเพิ่มรุ่นหลักเมื่อใด ...


ถ้าฉันมีคุณสมบัติมากกว่า 9 ฉันจะเขียน x.20.0 ได้ไหม?
Jemshit Iskenderov

@JemshitIskenderov แน่นอนคุณสามารถ
Pavel S.

35

ฉันใช้กฎนี้สำหรับแอปพลิเคชันของฉัน:

xyz

ที่ไหน:

  • x = หมายเลขรุ่นหลัก 1- ~
  • y = หมายเลขคุณลักษณะ 0-9 เพิ่มจำนวนนี้หากการเปลี่ยนแปลงมีคุณสมบัติใหม่ที่มีหรือไม่มีการแก้ไขข้อบกพร่อง
  • z = หมายเลขโปรแกรมแก้ไขด่วน 0- ~ เพิ่มจำนวนนี้หากการเปลี่ยนแปลงมีเพียงการแก้ไขข้อบกพร่อง

ตัวอย่าง:

  • สำหรับแอปพลิเคชันใหม่หมายเลขเวอร์ชันเริ่มต้นด้วย 1.0.0
  • หากเวอร์ชันใหม่มีเพียงการแก้ไขข้อบกพร่องให้เพิ่มหมายเลขโปรแกรมแก้ไขด่วนดังนั้นหมายเลขเวอร์ชันจะเป็น 1.0.1
  • หากเวอร์ชันใหม่มีคุณสมบัติใหม่ที่มีหรือไม่มีการแก้ไขข้อบกพร่องเพิ่มหมายเลขคุณลักษณะและรีเซ็ตหมายเลขโปรแกรมแก้ไขด่วนเป็นศูนย์ดังนั้นหมายเลขเวอร์ชันจะเป็น 1.1.0 หากหมายเลขคุณลักษณะถึง 9 ให้เพิ่มหมายเลขเวอร์ชันหลักและรีเซ็ตคุณสมบัติและหมายเลขโปรแกรมแก้ไขด่วนเป็นศูนย์ (2.0.0 เป็นต้น)

36
ฉันขอแนะนำให้ใช้ชุดรูปแบบนี้โดยไม่ต้องเลื่อน 9 -> 0 ในหมายเลข "คุณสมบัติ" / "โปรแกรมแก้ไขด่วน" เพียงไปที่ 10! การอัปเดตย่อย 10 รายการยังคงเป็นการอัปเดตเล็กน้อยหากมีการออกเพิ่มเติมแบบไม่มีข้อผิดพลาดกับ 1.10.0 หรือ 1.1.10
ttarik

4
.. และขึ้นไป ถ้าคุณมี 23 ฟีเจอร์ที่จะนำไปใช้ก่อน v.2 และจากนั้น 30 bugfixes ในฟีเจอร์สุดท้ายนั้น? คุณจะมีเวอร์ชั่น 1.23.30 รุ่นใหญ่รุ่นเป็นแนวคิดนามธรรมขนาดใหญ่ที่มีเหตุการณ์สำคัญบางอย่างไม่จำเป็นต้องปฏิบัติตามกฎการนับทศนิยมโดยพลการ
brianclements

11

เราใช้ abcd ที่ไหน

  • - ที่สำคัญ (เพิ่มขึ้นในการส่งมอบให้กับลูกค้า)
  • b - เล็กน้อย (เพิ่มขึ้นเมื่อส่งมอบให้กับลูกค้า)
  • c - การแก้ไข (เพิ่มขึ้นเมื่อมีการเผยแพร่ภายใน)
  • d - สร้าง (เพิ่มขึ้นโดยการควบคุมความเร็วคงที่)

5

แต่ตัวอย่างสำหรับอีกA.B.Cวิธีคือคราส Bundle รุ่น บันเดิล Eclipse ค่อนข้างจะมีเซ็กเมนต์ที่สี่:

ในคราสหมายเลขรุ่นจะประกอบด้วยสี่ (4) กลุ่ม: 3 major.minor.service.qualifierจำนวนเต็มและสตริงชื่อตามลำดับ แต่ละส่วนจับความตั้งใจที่แตกต่าง:

  • ส่วนที่สำคัญบ่งชี้ถึงการแตกใน API
  • ส่วนย่อยหมายถึงการเปลี่ยนแปลง "ภายนอกที่มองเห็นได้"
  • ส่วนงานบริการระบุถึงการแก้ไขข้อบกพร่องและการเปลี่ยนแปลงของกระแสการพัฒนา
  • ส่วนที่ผ่านการรับรองเป็นการระบุงานสร้างเฉพาะ

5

นอกจากนี้ยังมีโครงการวันเวอร์ชันเช่น: YYYY.MM, YY.MM,YYYYMMDD

มันค่อนข้างให้ข้อมูลเพราะรูปลักษณ์แรกให้ความประทับใจเกี่ยวกับวันที่วางจำหน่าย แต่ฉันชอบแบบ xyz เพราะฉันอยากรู้จุดที่แน่นอนของผลิตภัณฑ์ในวงจรชีวิตของมัน (Major.minor.release)


2

คำตอบพื้นฐานคือ "มันขึ้นอยู่กับ"

วัตถุประสงค์ของคุณในการกำหนดเวอร์ชันคืออะไร หลายคนใช้ version.revision.build และโฆษณา version.revision ไปทั่วโลกเท่านั้นเนื่องจากเป็นรุ่นวางจำหน่ายมากกว่ารุ่น dev หากคุณใช้การเช็คอิน 'เวอร์ชั่น' คุณจะพบว่าหมายเลขเวอร์ชั่นของคุณใหญ่อย่างรวดเร็ว

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

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


2

ดังที่ Mahesh พูดว่า: ฉันจะใช้เวอร์ชัน xyz

x - รุ่นใหญ่ y - รุ่นรอง z - หมายเลขบิลด์

คุณอาจต้องการเพิ่มวันที่และเวลาอาจเป็น z แทน

คุณเพิ่มรุ่นย่อยเมื่อคุณมีรุ่นอื่น รุ่นใหญ่อาจจะอยู่ที่ 0 หรือ 1 คุณเปลี่ยนว่าเมื่อคุณทำการเปลี่ยนแปลงที่สำคัญจริง ๆ (บ่อยครั้งเมื่อซอฟต์แวร์ของคุณอยู่ในจุดที่ไม่เข้ากันได้กับรุ่นก่อนหน้าหรือเปลี่ยนกรอบงานทั้งหมด)


2

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

หมายเลขเวอร์ชันแท็กมันคือทั้งหมดที่มี


2

เราปฏิบัติตามแนวทาง abc เช่น:

เพิ่ม 'a' หากมีการเปลี่ยนแปลงที่สำคัญเกิดขึ้นในแอปพลิเคชัน เช่นเดียวกับที่เราอัพเกรดแอปพลิเคชั่น. NET 1.1 เป็น. NET 3.5

increament 'b' หากมีการเปลี่ยนแปลงเล็กน้อยเช่น CR ใหม่หรือการปรับปรุงใด ๆ

เพิ่ม 'c' หากมีการแก้ไขข้อบกพร่องในรหัส


0

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

หากคุณเป็นเหมือนฉันคุณจะทำให้มันเป็นลูกผสมของวิธีการต่างๆเพื่อให้สอดคล้องกับการพัฒนาของซอฟต์แวร์ของคุณ

ฉันคิดว่ารูปแบบที่ยอมรับมากที่สุด abc หรือ abcd โดยเฉพาะอย่างยิ่งถ้าคุณมี QA / การปฏิบัติตามกฎระเบียบในการผสม ฉันมีจำนวนมากในวันที่เป็นส่วนหนึ่งของรุ่นปกติที่ฉันให้มันเป็นหลัก

ฉันไม่ได้ติดตามการสร้างดังนั้นฉันชอบที่จะใช้รูปแบบ abc ยกเว้นว่าเกี่ยวข้องกับโปรแกรมแก้ไขด่วน เมื่อฉันต้องใช้โปรแกรมแก้ไขด่วนแล้วฉันใช้พารามิเตอร์ d เป็นวันที่เวลา ฉันปรับใช้พารามิเตอร์เวลาเป็น d เพราะมักจะมีศักยภาพในหลาย ๆ ครั้งต่อวันเมื่อสิ่งต่าง ๆ เกิดขึ้นจริงในการผลิต ฉันใช้เฉพาะส่วน d (YYYYMMDDHHNN) เมื่อฉันเบี่ยงเบนความสนใจจากการแก้ไขการผลิต

โดยส่วนตัวฉันจะไม่เห็นด้วยกับรูปแบบซอฟต์แวร์ของ va.b revc โดยที่ c คือ YYYYMMDDHHMM หรือ YYYYMMMM

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.