โดยทั่วไปแล้วตัวเลขในเวอร์ชันแสดงถึงอะไร (เช่น v1.9.0.1)

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

ในเวอร์ชัน1.9.0.1 :

• 1 : การแก้ไขครั้งใหญ่ (UI ใหม่คุณสมบัติใหม่มากมายการเปลี่ยนแปลงแนวคิด ฯลฯ )

• 9 : การแก้ไขเล็กน้อย (อาจเป็นการเปลี่ยนแปลงในช่องค้นหา, เพิ่มคุณสมบัติ 1 รายการ, การรวบรวมการแก้ไขข้อบกพร่อง)

• 0 : รุ่นแก้ไขข้อบกพร่อง

• 1 : สร้างหมายเลข (ถ้าใช้) นั่นคือเหตุผลที่คุณเห็น. NET framework โดยใช้อะไรอย่างเช่น 2.0.4.2709

คุณจะไม่พบแอปจำนวนมากที่ลดระดับลงถึง 4 ระดับโดยปกติแล้ว 3 ก็เพียงพอแล้ว

มีข้อกำหนดการกำหนดเวอร์ชันความหมาย

นี่คือข้อมูลสรุปของเวอร์ชัน 2.0.0:

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

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

ป้ายกำกับเพิ่มเติมสำหรับข้อมูลเมตารุ่นก่อนวางจำหน่ายและรุ่นสร้างพร้อมใช้งานเป็นส่วนขยายของรูปแบบ MAJOR.MINOR.PATCH

อาจเป็นไปโดยพลการมากและแตกต่างจากผลิตภัณฑ์ไปสู่ผลิตภัณฑ์ ตัวอย่างเช่นด้วยการแจกจ่าย Ubuntu 8.04 หมายถึง 2008 เมษายน

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

major.minor [.maintenance [.build]]

http://en.wikipedia.org/wiki/Software_versioning#Numeric

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

ตัวอย่างเช่น WordPress ไปตามบรรทัดเหล่านี้:

1.6 -> 2.0 -> 2.0.1 -> 2.0.2 -> 2.1 -> 2.1.1 -> 2.2 ...

1.6 ถึง 2.0 จะเป็นการเปิดตัวครั้งใหญ่ - คุณสมบัติการเปลี่ยนแปลงอินเทอร์เฟซการเปลี่ยนแปลงที่สำคัญของ API การแตกของเทมเพลตและปลั๊กอิน 1.6 บางตัวเป็นต้น 2.0 ถึง 2.0.1 อาจเป็นรุ่นย่อย - อาจแก้ไขข้อบกพร่องด้านความปลอดภัย 2.0.2 ถึง 2.1 จะเป็นรุ่นที่สำคัญซึ่งโดยทั่วไปแล้วคุณลักษณะใหม่ ๆ

ตัวเลขอาจมีประโยชน์ตามที่อธิบายไว้ในคำตอบอื่น ๆ แต่ลองพิจารณาดูว่ามันอาจจะค่อนข้างไร้ความหมายได้อย่างไร ... อาทิตย์คุณรู้จัก SUN, java: 1.2, 1.3, 1.4 1.5 หรือ 5 แล้ว 6. ใน Apple II เวอร์ชันเก่า ๆ บางสิ่งบางอย่าง ปัจจุบันผู้คนเลิกใช้หมายเลขเวอร์ชันและใช้ชื่อโง่ ๆ เช่น "Feisty fig" (หรืออะไรทำนองนั้น) และ "นกกระสาบึกบึน" และ "europa" และ "ganymede" แน่นอนว่าสิ่งนี้มีประโยชน์น้อยกว่ามากเพราะคุณจะหมดดวงจันทร์ของดาวพฤหัสบดีก่อนที่คุณจะหยุดเปลี่ยนโปรแกรมและเนื่องจากไม่มีลำดับที่ชัดเจนคุณจึงไม่สามารถบอกได้ว่าอันไหนใหม่กว่า

ในเวอร์ชัน v1.9.0.1: นี่คือรูปแบบการกำหนดเวอร์ชันที่ชัดเจนที่ใช้เมื่อคุณไม่ต้องการใช้ชื่อสำหรับรุ่นก่อนเผยแพร่หรือสร้างเช่น -alpha, -beta

1: เวอร์ชันหลักซึ่งอาจทำลายความเข้ากันได้แบบย้อนหลัง

9: การเพิ่มคุณสมบัติใหม่เพื่อรองรับแอพของคุณพร้อมกับความเข้ากันได้ย้อนหลังกับเวอร์ชันก่อนหน้า

0: การแก้ไขข้อบกพร่องเล็กน้อยบางอย่าง

1: หมายเลขรุ่น (หมายเลขรุ่นก่อนวางจำหน่าย)

แต่ในปัจจุบันคุณจะไม่พบรูปแบบการกำหนดเวอร์ชันดังกล่าวโปรดดู Semantic Versioning [semver2.0] https://semver.org/

หมายเลขเวอร์ชันมักไม่ได้แสดงถึงส่วนประกอบที่แยกจากกัน สำหรับบางคน / ซอฟต์แวร์ตัวเลขนั้นค่อนข้างเป็นไปตามอำเภอใจ สำหรับคนอื่น ๆ ส่วนต่างๆของสตริงหมายเลขเวอร์ชันจะแสดงถึงสิ่งที่แตกต่างกัน ตัวอย่างเช่นบางระบบจะเพิ่มบางส่วนของหมายเลขเวอร์ชันเมื่อรูปแบบไฟล์เปลี่ยนไป ดังนั้น V 1.2.1 จึงเป็นรูปแบบไฟล์ที่เข้ากันได้กับเวอร์ชันอื่น ๆ ของ V 1.2 (1.2.2, 1.2.3 ฯลฯ ) แต่ไม่ใช่กับ V 1.3 ท้ายที่สุดแล้วขึ้นอยู่กับคุณว่าคุณต้องการใช้รูปแบบใด

โดยปกติแล้ว:

MajorVersion.MinorVersion.Revision.Build

มันขึ้นอยู่ แต่การแสดงโดยทั่วไปเป็นที่ของmajor.minor.release.build

ที่ไหน:

• majorเป็นเวอร์ชันหลักของซอฟต์แวร์ของคุณคิดว่า. NET 3.x
• minorคือซอฟต์แวร์รุ่นรองของคุณคิดว่า. NET x.5
• releaseคือการเปิดตัวของเวอร์ชันนั้นโดยทั่วไปการแก้ไขข้อบกพร่องจะเพิ่มสิ่งนี้
• buildคือตัวเลขที่แสดงถึงจำนวนบิลด์ที่คุณทำ

ตัวอย่างเช่น 1.9.0.1 หมายความว่าเป็นเวอร์ชัน 1.9 ของซอฟต์แวร์ของคุณตามหลัง 1.8 และ 1.7 เป็นต้นโดยที่ 1.7, 1.8 และ 1.9 โดยทั่วไปแล้วจะเพิ่มคุณสมบัติใหม่จำนวนเล็กน้อยควบคู่ไปกับการแก้ไขข้อบกพร่อง เนื่องจากเป็น xx0.x จึงเป็นรุ่นแรกของ 1.9 และเป็นรุ่นแรกของเวอร์ชันนั้น

คุณยังสามารถค้นหาข้อมูลที่ดีได้จากบทความ Wikipedia ในหัวข้อนี้

รายใหญ่ผู้เยาว์ข้อบกพร่อง

(หรือการเปลี่ยนแปลงบางอย่าง)

ข้อบกพร่องมักเป็นการแก้ไขข้อบกพร่องโดยไม่มีฟังก์ชันใหม่

ไมเนอร์คือการเปลี่ยนแปลงบางอย่างที่เพิ่มฟังก์ชันการทำงานใหม่ ๆ แต่ไม่ได้เปลี่ยนแปลงโปรแกรมในลักษณะสำคัญใด ๆ

Major คือการเปลี่ยนแปลงในโปรแกรมที่ทำลายฟังก์ชันการทำงานเก่าหรือมีขนาดใหญ่มากจนเปลี่ยนวิธีที่ผู้ใช้ควรใช้โปรแกรม

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

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

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

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

เกินตำแหน่ง "3"? ฉันไม่รู้ว่าทำไมคนถึงทำแบบนั้นมันสับสนมากขึ้น

โดยเฉพาะอย่างยิ่ง OSS บางตัวที่มีอยู่ทำให้ทั้งหมดนี้หมดไป ตัวอย่างเช่น Trac เวอร์ชัน 10 คือ 0.10.XX ฉันคิดว่าผู้คนจำนวนมากในโลก OSS อาจขาดความมั่นใจหรือไม่ต้องการประกาศว่าพวกเขามีการเปิดตัวครั้งใหญ่

จากไฟล์ C # AssemblyInfo.cs คุณสามารถดูสิ่งต่อไปนี้:

// Version information for an assembly consists of the following four values:
//
//      Major Version
//      Minor Version 
//      Build Number
//      Revision
//
/ You can specify all the values or you can default the Build and Revision Numbers 
// by using the '*' as shown below:
// [assembly: AssemblyVersion("1.0.*")]

release.major.minor.revision จะเป็นการคาดเดาของฉัน
แต่อาจแตกต่างกันอย่างมากระหว่างผลิตภัณฑ์

Major.minor.point.build โดยปกติ รายใหญ่และรายย่อยสามารถอธิบายตนเองได้ประเด็นคือการเปิดตัวสำหรับการแก้ไขข้อบกพร่องเล็กน้อยและการสร้างเป็นเพียงตัวระบุการสร้าง

ได้. รุ่นใหญ่เพิ่มคุณสมบัติใหม่ขนาดใหญ่อาจทำลายความเข้ากันได้หรือมีการอ้างอิงที่แตกต่างกันอย่างมีนัยสำคัญ ฯลฯ

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

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

ฉันคิดว่ากระบวนทัศน์ของรุ่นหลัก release.minor release.bug เป็นเรื่องธรรมดา

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

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

ถ้าเป็นไปได้ให้เปิดเผยหมายเลขเวอร์ชันที่ง่ายกว่านี้ให้กับลูกค้าของคุณ

ในกรณีของไลบรารีหมายเลขเวอร์ชันจะบอกคุณเกี่ยวกับระดับความเข้ากันได้ระหว่างสองรีลีสดังนั้นการอัปเกรดจะยากเพียงใด

รุ่นแก้ไขข้อบกพร่องจำเป็นต้องรักษาความเข้ากันได้ของไบนารีซอร์สและอนุกรม

รุ่นย่อยหมายถึงสิ่งที่แตกต่างกันสำหรับโครงการต่างๆ แต่โดยปกติแล้วไม่จำเป็นต้องรักษาความเข้ากันได้ของแหล่งที่มา

หมายเลขเวอร์ชันหลักสามารถทำลายทั้งสามรูปแบบได้

ผมเขียนเพิ่มเติมเกี่ยวกับเหตุผลที่นี่

การรวมกันของหลักรองโปรแกรมแก้ไขสร้างโปรแกรมปรับปรุงความปลอดภัย ฯลฯ

สองรายการแรกเป็นรายใหญ่และรายย่อยส่วนที่เหลือจะขึ้นอยู่กับโครงการ บริษัท และบางครั้งชุมชน ในระบบปฏิบัติการเช่น FreeBSD คุณจะมี 1.9.0.1_number เพื่อแสดงถึงแพตช์ความปลอดภัย

ขึ้นอยู่กับภาษาเล็กน้อยเช่น Delphi และ C # มีความหมายต่างกัน

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

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

เล็ก ๆ น้อย ๆ รายละเอียดอีกเล็กน้อยที่นี่ "อย่างเป็นทางการ" ใน. net ตัวเลข 4 ตัวคือ "Major.Minor.Build.Revision" ในขณะที่ใน Delphi มี "Major.Minor.Release.Build" ฉันใช้ "Major.Minor.ReallyMinor.SubversionRev" สำหรับการกำหนดเวอร์ชันของฉัน

โดยทั่วไปแล้วตัวเลขจะอยู่ในรูปแบบของ version.major.minor.hotfix ไม่ใช่ส่วนประกอบภายในแต่ละส่วน ดังนั้น v1.9.0.1 จะเป็นเวอร์ชัน 1, รุ่นหลัก 9 (ของ v1), รุ่นรอง (ของ v1.9) 0, โปรแกรมแก้ไขด่วน 1 ของ (v1.9.0)

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

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

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

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

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

หมายเลขเวอร์ชันของซอฟต์แวร์ที่ซับซ้อนแสดงถึงแพ็กเกจทั้งหมดและไม่ขึ้นอยู่กับหมายเลขเวอร์ชันของชิ้นส่วน Gizmo เวอร์ชัน 3.2.5 อาจมี Foo เวอร์ชัน 1.2.0 และ Bar เวอร์ชัน 9.5.4

เมื่อสร้างหมายเลขเวอร์ชันให้ใช้ดังต่อไปนี้:

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

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

3. การกำหนดหมายเลขเวอร์ชันเพิ่มเติมขึ้นอยู่กับผู้ที่เขียนซอฟต์แวร์ - Oracle ใช้กลุ่ม (!) ห้ากลุ่ม ได้แก่ เวอร์ชัน Oracle ก็เหมือนกับ 10.1.3.0.5 จากกลุ่มที่สามคุณควรแนะนำเฉพาะการแก้ไขข้อบกพร่องหรือการเปลี่ยนแปลงเล็กน้อยในฟังก์ชันการทำงาน

สิ่งที่แตกต่างกันน้อยกว่าจะเป็นสองตัวแรกสำหรับ major.min หรือหลังจากนั้นอาจเป็นอะไรก็ได้ตั้งแต่การสร้างการแก้ไขการเผยแพร่ไปจนถึงอัลกอริทึมที่กำหนดเอง (เช่นในผลิตภัณฑ์ MS บางอย่าง)

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

x.yz.bbbbb. โดยที่: x: เป็นเวอร์ชันหลัก (คุณสมบัติใหม่ที่สำคัญ) y: เป็นหมายเลขเวอร์ชันรอง (คุณสมบัติใหม่ขนาดเล็กการปรับปรุงเล็กน้อยโดยไม่มีการเปลี่ยนแปลง UI) z: คือ service pack (โดยทั่วไปเหมือนกับ xy แต่มีการแก้ไขข้อบกพร่องบางอย่าง bbbb: เป็นหมายเลขรุ่นและสามารถมองเห็นได้จาก "กล่องเกี่ยวกับ" พร้อมรายละเอียดอื่น ๆ สำหรับการสนับสนุนลูกค้าเท่านั้น bbbb เป็นรูปแบบฟรีและผลิตภัณฑ์ทุกชิ้นสามารถใช้เป็นของตัวเองได้

นี่คือสิ่งที่เราใช้:

1. หมายเลขแรก = ยุคของระบบโดยรวม มีการเปลี่ยนแปลงทุกๆสองสามปีและโดยทั่วไปจะแสดงถึงการเปลี่ยนแปลงขั้นพื้นฐานของเทคโนโลยีหรือคุณลักษณะของไคลเอ็นต์หรือทั้งสองอย่าง
2. หมายเลขที่สอง = การแก้ไขสคีมาฐานข้อมูล การเพิ่มจำนวนนี้จำเป็นต้องมีการย้ายฐานข้อมูลดังนั้นจึงเป็นการเปลี่ยนแปลงที่สำคัญ (หรือระบบจำลองและการเปลี่ยนโครงสร้างฐานข้อมูลจึงต้องใช้กระบวนการอัปเกรดอย่างรอบคอบ) รีเซ็ตเป็น 0 หากตัวเลขแรกเปลี่ยนไป
3. หมายเลขที่สาม = ซอฟต์แวร์เท่านั้นที่เปลี่ยนแปลง โดยปกติแล้วสิ่งนี้สามารถนำไปใช้กับไคลเอนต์โดยพื้นฐานของไคลเอ็นต์เนื่องจากสคีมาฐานข้อมูลไม่มีการเปลี่ยนแปลง รีเซ็ตเป็นศูนย์หากตัวเลขที่สองเปลี่ยนไป
4. หมายเลขเวอร์ชันการโค่นล้ม เราเติมข้อมูลนี้โดยอัตโนมัติในบิลด์โดยใช้เครื่องมือ TortoiseSVN หมายเลขนี้ไม่เคยรีเซ็ต แต่จะเพิ่มขึ้นเรื่อย ๆ การใช้สิ่งนี้ทำให้เราสามารถสร้างเวอร์ชันใดก็ได้

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

เวอร์ชัน: v1.9.0.1

ที่ไหน -

. v คือตัวย่อของเวอร์ชัน มันแตกต่างกันไปในแต่ละ บริษัท ขึ้นอยู่กับระบบการตั้งชื่อที่นำมาใช้ในองค์กรของเขา อาจเงียบในบางองค์กรเช่น 1.9.0.1

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

. 9 incates minor จะได้รับการอัปเดตเกี่ยวกับกิจกรรมเช่นการเพิ่มส่วนประกอบใหม่เช่น ui, api, database ฯลฯ ภายใต้สถาปัตยกรรมเฉพาะ

. 0 หมายถึงคุณลักษณะจะได้รับการอัปเดตเกี่ยวกับการปรับปรุงใด ๆ ของส่วนประกอบที่มีอยู่ (ui, api, ฐานข้อมูล ฯลฯ )

. 1 หมายถึงตัวนับการสร้างในทุกเฟสหลักรองและคุณลักษณะ นอกจากนี้ยังรวมโปรแกรมแก้ไขด่วนรุ่นหลังการผลิต