คุณเปลี่ยนหมายเลขรุ่นหลัก / รอง / โปรแกรมปรับปรุงเมื่อใด

ซ้ำได้:
คุณใช้“ แบบแผนการตั้งชื่อเวอร์ชัน” อะไร

คุณเปลี่ยนหมายเลขรุ่นหลัก / รอง / แพตช์ของคุณทันทีก่อนที่คุณจะวางจำหน่ายหรือหลังจากนั้น

ตัวอย่าง: คุณเพิ่งปล่อย 1.0.0 สู่โลก (huzzah!) แต่เดี๋ยวก่อนอย่าฉลองมากเกินไป 1.1.0 ออกมาในอีกหกสัปดาห์! ดังนั้นคุณจึงแก้ไขข้อผิดพลาดและสร้างงานใหม่ งานสร้างนั้นเรียกว่าอะไร? 1.1.0.0 หรือ 1.0.0.xxxy (โดยที่ xxxy คือหมายเลขบิลด์ที่เพิ่มขึ้น 1.0.0)?

โปรดทราบว่าคุณอาจมีคุณสมบัติและข้อบกพร่อง 100 ข้อที่จะเข้าสู่ 1.1.0 ดังนั้นอาจเป็นการดีที่จะเรียกมันว่า 1.0.0.xxxy เพราะคุณอยู่ใกล้กับ 1.1.0 แล้ว แต่ในทางกลับกัน dev อื่นอาจทำงานบน 2.0.0 ซึ่งในกรณีนี้งานสร้างของคุณอาจชื่อ 1.1.0.0 และ 2.0.0.0 ดีกว่าแทนที่จะเป็น 1.0.0.xxxy และ 1.0.0.xxxz ตามลำดับ

หลังจากคุณเผยแพร่ซอฟต์แวร์หมายเลขรุ่นควรเพิ่มขึ้นทันที

ทำไม?

สมมติว่าคุณกำลังติดตามรูปแบบการกำหนดเวอร์ชันแบบ Semanticและคุณมีหมายเลขบิลด์ในเวอร์ชัน ดังนั้นคุณอาจมี [Major]. [Minor]. [Patch]. [Build] ฉันจะเรียก [Major]. [Minor]. [Patch] เป็นส่วนของเวอร์ชั่น

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

หากคุณกำลังเตรียมพร้อมสำหรับการเปิดตัวและซอฟต์แวร์ผ่านการทดสอบทั้งหมดคุณจะไม่ต้องการสร้างและทดสอบซ้ำซอฟต์แวร์เพียงเพราะคุณต้องอัปเดตเวอร์ชัน ในที่สุดเมื่อคุณวางจำหน่ายคุณจะระบุว่า "build 1.1.0.23" ต่อจากนี้ไปจะเรียกว่า "version 1.1.0"

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

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

ในระหว่างการพัฒนาผมพยายามที่จะเปลี่ยนหมายเลขรุ่นตรงไป (ถ้าเป็นไปได้) บางครั้งมันก็ยากที่จะรู้ว่าการเปลี่ยนแปลงจะเป็นการเปลี่ยนแปลงที่เกิดขึ้นหรือไม่ (ซึ่งจะมีผลต่อหมายเลขรุ่นของฉัน) ดังนั้นจึงไม่มีอะไร "ตั้งอยู่ในหิน"

ในการระบุตัวอย่างเฉพาะของคุณ:

• ในระหว่างการพัฒนาเวอร์ชั่นพรี - รีลีสคือ 1.0.1-alpha.1, 1.0.1-alpha.2 เป็นต้น
• รุ่นสุดท้ายของการแก้ไขข้อผิดพลาดจะเป็นรุ่น 1.0.1

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

ลองสมมติ ABCD ในคำตอบ เมื่อไหร่ที่คุณจะเพิ่มส่วนประกอบแต่ละส่วน?

มันถูกกำหนดโดยทั่วไปตามนโยบาย บริษัท ของคุณ นโยบาย บริษัท ของเราคือ:

• เอ - การเปลี่ยนแปลงหรือเพิ่มเติมที่สำคัญ (> 25%) ในฟังก์ชันหรืออินเทอร์เฟซ
• B - การเปลี่ยนแปลงเล็กน้อยหรือเพิ่มเติมในการทำงานหรืออินเตอร์เฟซ
• C - การเปลี่ยนแปลงเล็กน้อยที่ทำลายอินเตอร์เฟซ
• D - แก้ไขการสร้างที่ไม่ได้เปลี่ยนอินเตอร์เฟซ

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

หมายเลขการสร้างหลักและรอง (c และ d ใน abcd) มักจะถูกควบคุมโดยการพัฒนา c คือหมายเลขบิลด์และ d ใช้สำหรับแพทช์ในรีลีสเฉพาะหรือเวอร์ชันของ c

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

เราพยายามและทำตามตัวอย่างคราส มันอธิบายได้ดีกว่าที่ฉันทำได้ แต่มีประสิทธิภาพสำหรับเราที่จะทำงานเช่นนี้:

เมื่อคุณปล่อย 1.0.0.0 หมายเลขรุ่นที่คุณเปลี่ยนจะขึ้นอยู่กับประเภทของการเปลี่ยนแปลงที่คุณทำ

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

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

ไม่มีงานสร้างต่อไป บนสาขานั้น

เวอร์ชันในอุดมคติของโครงการของเรา

การระบุเวอร์ชันในสาขาใดก็ได้คือ PRETTY_BRANCH_NAME-build และ PRETTY_BRANCH_NAME ได้รับการแก้ไขเมื่อสร้างสาขา

รูปแบบการแตกแขนงของเรา (*) มีดังต่อไปนี้:

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

• สาขา TNG ( รุ่นต่อไป ) ที่มีการพัฒนาระยะยาว บ่อยครั้งที่เราไม่ได้มีมันและมันก็ไม่เคย (ย่อย) สาขาย่อย

• สาขา TCG ( ยุคปัจจุบัน ) ที่มีการพัฒนาในปัจจุบัน PRETTY_BRANCH_NAME เป็นชื่อรหัส

• สาขา TPG ( รุ่นก่อนหน้า ) มักจะไม่มีการพัฒนาเพิ่มเติมที่นี่ แต่อาจมีกิจกรรมในสาขาย่อย

สาขาย่อยทำจากสาขาระดับบนสุด (ของ TCG เมื่อมีการย้ายข้อมูลช้าของ TPG) เมื่อเบต้าสำหรับการเปิดตัวครั้งใหญ่ PRETTY_BRANCH_NAME นั้นคล้ายกับ "1.3.X" (X คือตัวอักษรไม่ใช่หลักหมายถึงเราตั้งใจที่จะส่งมอบ 1.3 รุ่นจากที่นี่) ข้อเสนอแนะจากเบต้าคือโทเค็นเข้าบัญชีที่นี่ในขณะที่ทำงานสำหรับรุ่นใหญ่ครั้งต่อไป สาขา TCG

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

ถ้าเรามีระดับที่สี่ชื่อย่อยจะเป็น "1.3.0.X" ซึ่งเรามีย่อย ^ 3 สาขา "1.3.0.0" "1.3.0.1"

(*) ที่ระดับการเปิดตัว อาจมีสาขาย่อยของโครงการในแต่ละเหล่านี้

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

หากคุณมีการควบคุมแล้ว:

1. รุ่นใหญ่เมื่อ:

   • มีความเข้ากันไม่ได้กับรีลีสก่อนหน้านี้ที่ต้องการการแปลงเป็นต้นเช่นจาก Python 2 ถึง Python 3

   • มีฟังก์ชั่นใหม่ทั้งหมด

2. ไมเนอร์เปิดตัวสำหรับการเปลี่ยนแปลงเล็ก ๆ น้อย ๆ ในการทำงาน

3. การเปิดตัวแก้ไขสำหรับการแก้ไขข้อบกพร่อง