หมายเลขรุ่นทำอย่างไร?

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

[ สำคัญ ]. [ เล็กน้อย ]. [ ปล่อย ]. [ สร้าง ]

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

เล็กน้อย : เริ่มต้นจาก 0 เมื่อใดก็ตามที่สำคัญเพิ่มขึ้น +1 สำหรับทุกรุ่นที่เผยแพร่สู่สาธารณะ

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

build : สามารถแก้ไข SVN ได้ฉันพบว่าทำงานได้ดีที่สุด

ตัวอย่าง
โครเมียมปัจจุบันของฉัน: 83.0.4103.61

xyzg

เพิ่มขึ้นใน g จะไม่เสถียร การเพิ่มขึ้นของ (หรือ RC) ใน z นั้นเสถียรและหมายถึงการแก้ไขข้อบกพร่อง
เพิ่มขึ้นใน y มีความเสถียรและคุณสมบัติใหม่หมายถึง
การเพิ่มขึ้นของ x จะเสถียรปล่อยที่สำคัญโดยไม่มีความเข้ากันได้ย้อนหลัง 100%

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

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

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

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

แก้ไข 2:มีคนพอพบว่าบทความของฉันมีประโยชน์ในการทำให้เป็น "คำตอบที่ดี" ฉันเริ่มทำงานกับบทความอีกครั้ง ขณะนี้มีเวอร์ชั่น PDF และ LaTeX แล้วการเขียนใหม่ที่สมบูรณ์รวมถึงภาษาที่ดีกว่าและกราฟิกที่อธิบายจะตามมาทันทีที่ฉันสามารถหาเวลาได้ ขอบคุณสำหรับคะแนนโหวต!

รับแรงบันดาลใจจาก Wikipedia: "Software versioning"

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

สรุป:

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

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

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

เอบีซีดี

เพิ่มขึ้น: เมื่อ
- d : แก้ไขข้อผิดพลาด
- c : การบำรุงรักษาเช่นการปรับปรุงประสิทธิภาพ
- b : คุณสมบัติใหม่
- a : การเปลี่ยนแปลงสถาปัตยกรรม

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

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

โดยทั่วไปจะสร้างออกจากความหมายของรุ่น 2.0แต่ไม่ได้ค่อนข้างเป็นที่เข้มงวด

กลุ่มเวอร์ชันกึ่งความหมาย:

<primary.release.segment>[-<pre.release.segment>][+<post.release.segment>]

รูปแบบส่วนที่วางจำหน่ายหลัก:

MARKETTING.MAJOR.MINOR.PATCH

แต่ละเซกเมนต์ควรอนุญาตให้ใช้ตัวอักษรและตัวเลข แต่แนะนำให้ใช้ตัวเลขล้วนสำหรับการเปลี่ยนแปลงเชิงตรรกะแบบส่วนเพิ่ม

เช่นเดียวกับ SemVer ฉันแนะนำคอมโพเนนต์ Major, Minor และ Patchเพื่อแสดงระดับความเข้ากันได้ย้อนกลับ แต่ฉันยังแนะนำให้เตรียมส่วนประกอบการตลาดไว้ด้วย สิ่งนี้ช่วยให้เจ้าของผลิตภัณฑ์มหากาพย์คุณลักษณะ / กลุ่มและข้อกังวลทางธุรกิจกระแทกส่วนประกอบหลักโดยไม่เกี่ยวข้องกับความเข้ากันได้ทางเทคนิค

ต่างจากคำตอบอื่น ๆ ฉันไม่แนะนำให้เพิ่มหมายเลข Build ต่อท้ายกลุ่มหลัก เพิ่มกลุ่มโพสต์เผยแพร่ '+' (เช่น: 1.1.0.0 + build.42) SemVer เรียกการสร้างเมตาดาต้านี้ แต่ผมคิดว่าโพสต์ที่วางจำหน่ายส่วนงานที่ชัดเจน ส่วนนี้เหมาะอย่างยิ่งสำหรับการประกาศข้อมูลส่วนต่อท้ายซึ่งไม่เกี่ยวข้องกับข้อมูลความเข้ากันได้ในส่วนการเผยแพร่หลักแทน บิวด์การรวมอย่างต่อเนื่องของคุณสามารถกำหนดหมายเลขรีลีสก่อนหน้าต่อท้ายด้วยหมายเลขบิลด์ที่เพิ่มขึ้นซึ่งจะรีเซ็ตหลังจากรีลีสหลักแต่ละครั้ง (เช่น 1.1.0.0 -> 1.1.0.0 + build.1 -> 1.1.0.0 + build.2 -> 1.1.0.1) บางคนสลับกันชอบใส่หมายเลขการแก้ไข svn ที่นี่หรือคอมไพล์กำหนด sha เพื่อให้ง่ายต่อการผูกกับที่เก็บรหัส อีกตัวเลือกหนึ่งคือการใช้กลุ่มโพสต์เผยแพร่สำหรับโปรแกรมแก้ไขด่วนและโปรแกรมแก้ไขซึ่งอาจคุ้มค่าที่จะพิจารณาการเพิ่มส่วนประกอบรุ่นหลักใหม่ มันสามารถลดลงได้ตลอดเวลาเมื่อมีการเพิ่มส่วนประกอบของแพตช์

นอกเหนือไปจากการเปิดตัวและหลังการเปิดตัวกลุ่มคนมักจะต้องการใช้ส่วนงาน Pre-Releaseเพื่อบ่งชี้ถึงเกือบมั่นคงก่อนเผยแพร่เหมือน alphas, เบต้าและผู้สมัครที่ปล่อย วิธี SemVer นี้ทำงานได้ดี แต่ผมขอแนะนำให้แยกส่วนประกอบตัวเลขจากลักษณนามตัวเลข (เช่น: 1.2.0.0 + alpha.2 หรือ 1.2.0.0 + RC.2) โดยปกติคุณจะชนกลุ่มปล่อยในเวลาเดียวกันกับการเพิ่มกลุ่มโพสต์ปล่อยแล้ววางกลุ่มก่อนปล่อยเมื่อคุณชนพวกเขาต่อไปกลุ่มปล่อยหลัก (เช่น: 1.0.1.2 -> 1.2.0.0-RC.1 - > 1.2.0.0) เพิ่มกลุ่มที่มีการวางจำหน่ายล่วงหน้าเพื่อระบุว่ารุ่นวางจำหน่ายกำลังจะเกิดขึ้นซึ่งโดยปกติจะเป็นเพียงชุดของคุณลักษณะที่กำหนดไว้สำหรับการทดสอบและการแบ่งปันในเชิงลึกที่ไม่เปลี่ยนแปลงจากนาทีต่อนาทีตามความมุ่งมั่นที่มากขึ้น

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

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

"หมายเลขเวอร์ชั่น" เป็นเรื่องสำคัญสำหรับระบบควบคุมเวอร์ชันภายในของคุณ หมายเลขรุ่นมีความแตกต่างกัน (และควรแตกต่างจาก KEPT)

ติดกับระบบปล่อย MAJOR.MINOR ง่าย (เช่น v1.27) ที่สำคัญคือระดับความเข้ากันได้ (รุ่น 2.x ไม่เข้ากันกับหรืออย่างน้อย majorly แตกต่างจากรุ่น 1.x) และรองลงมาเป็นรุ่น bugfix ของคุณหรือการปรับปรุงเล็กน้อย . ตราบใดที่คุณทำตามรูปแบบ XY คุณสามารถใช้ระบบอื่นเช่น YEAR.MONTH (2009.12) หรือ YEAR.RELEASE (2009.3) แต่จริงๆแล้วคุณน่าจะยึด MAJOR.MINOR ได้ดีที่สุดถ้าคุณไม่มีเหตุผลที่ดี

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

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

และใช่ 1.0 ควรมีเสถียรภาพ ทุกรุ่นที่ออกควรจะมีเสถียรภาพเว้นแต่พวกเขากำลังทำเครื่องหมายอัลฟ่าเบต้าหรือ RC ใช้สำหรับจุดเริ่มรู้จักกันเสียและไม่สมบูรณ์ Betas สำหรับที่รู้จักกันหัก RCs สำหรับ "ลองดูคุณอาจจะเห็นสิ่งที่เราพลาด" สิ่งใดที่ไม่มีสิ่งเหล่านี้ควรทดสอบ (ดีเลิศแน่นอน) เป็นที่รู้จักดีมีคู่มือที่ทันสมัย ​​ฯลฯ

เป็นที่นิยมในสมัยนี้เพียงแค่ใช้หมายเลขการแก้ไขการโค่นล้ม

ถ้ามันอยู่ใน SVN แล้วทำไมไม่ใช้จำนวนการแก้ไข SVN?

หากคุณดูที่ด้านล่างขวาของหน้าเว็บนี้คุณจะเห็นหมายเลขรุ่น Stack Overflow ซึ่งเป็นหมายเลขการแก้ไข SVN

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

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

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

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

หมายเลขรุ่นคลาสสิคมักจะเผยแพร่ "ละคร" เพื่อให้ผู้ใช้สามารถสร้างความคาดหวังบางอย่าง มันง่ายกว่าที่จะคิดว่า "ฉันมีรุ่น 1.0 แล้วตอนนี้รุ่น 1.1 กำลังเพิ่มสิ่งนี้และนั่นฟังดูน่าสนใจ" กว่าที่จะคิดว่า "เมื่อวานนี้เราได้ดำเนินการแก้ไขในปี 2587 แล้ววันนี้คือ 3233 วันนี้

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

รูปแบบเวอร์ชัน: [สำคัญ]. [เล็กน้อย]. [devrel] [เครื่องหมาย]
[สำคัญ]: เพิ่มขึ้นหากคุณมีการเปลี่ยนแปลงที่รุนแรงในการพัฒนา
[เล็ก ๆ น้อย ๆ ]: เพิ่มขึ้นถ้าคุณมีการเปลี่ยนแปลงเล็กน้อยในการพัฒนา
[devrel]: เพิ่มขึ้นถ้าคุณมีการแก้ไขข้อบกพร่อง รีเซ็ตเป็นศูนย์ถ้าสำคัญ ++ หรือเล็กน้อย ++
[เครื่องหมาย]: a, b หรือ rc: a คือการปลดปล่อยอัลฟา, b คือการปล่อยเบต้าและ rc เป็นตัวเลือกการเปิดตัว โปรดทราบว่ารุ่นเช่น 1.3.57a หรือ 1.3.57b หรือ 1.3.57rc คือก่อนรุ่น 1.3.57 เริ่มต้นที่ 0.0.0

เราใช้เวลามากเกินไปในการตัดสินใจว่าจะเพิ่มรุ่นหลักหรือไม่ ร้านค้าบางแห่งจะไม่ค่อยทำเช่นนั้นดังนั้นคุณจะได้รับการเผยแพร่เช่น 1.25.3 และร้านอื่น ๆ จะทำเพื่อให้คุณปล่อย 15.0

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

Year.Release.build

• ปี = ปีปัจจุบัน
• ปล่อย = ลำดับ # เผยแพร่สาธารณะที่มีฟังก์ชันการทำงานใหม่ - รีเซ็ต 1 ทุกปี
• build = เพิ่มค่าสำหรับการแก้ไขบั๊กและรีลีสภายใน

แก้ไข

** ตอนนี้เป็นแอพภายในที่ได้รับการปรับปรุงอย่างต่อเนื่อง **

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

เหตุผลที่ว่าทำไมคำถามนี้มีอยู่เป็นเพราะเราไม่ได้มีคนเดียวตามที่ตกลงกันวิธีการทำจัดการการกำหนดค่า

วิธีที่ฉันชอบทำหมายเลขรุ่นเป็นเพียงการเพิ่มจำนวนเต็มจาก 1 ฉันไม่ต้องการหมายเลขรุ่นหลายส่วนที่ฉันจะต้องอธิบายหรือเอกสาร และฉันไม่ต้องการใช้หมายเลข rev SVN เพราะจะต้องอธิบายด้วยเช่นกัน

คุณจะต้องมีสคริปต์การเปิดตัวที่ด้านบนของ SVN เพื่อให้เกิดสิ่งนี้

ฉันมีประสบการณ์น้อยมากในพื้นที่ อย่างไรก็ตามนี่คือสิ่งที่ฉันจะทำ:

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

แน่นอนคุณสามารถใช้หมายเลขการแก้ไข svn ได้เหมือนที่คนอื่น ๆ แนะนำ !!!

ฉันหวังว่านี่จะช่วยได้.

เราใช้ซินแท็กซ์ major.minor.julian_date แบบง่าย ๆ

ไหน;

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

ตัวอย่างของการเปิดตัวครั้งแรกที่ผลักดันให้ QA เมื่อวันที่ 1/15 คือ -> 1.0.015
ตัวอย่างของการเปิดตัวครั้งแรกที่ผลักดันให้ QA เมื่อวันที่ 1/15 คือ -> 1.1.063

มันไม่สมบูรณ์แบบ แต่มีประโยชน์เพราะเราผลักดันงานสร้าง QA ใกล้ ๆ ทุกวัน

ข้อมูลที่ดีบางอย่างที่นี่:

เมื่อการเปลี่ยนไฟล์ / รุ่นสมัชชา

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

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

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

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

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

หรือใช้หมายเลขเวอร์ชัน 'เครื่องหมาย' การลบโควต้าของคุณ 'zB:

1.0.101 // การแก้ไข 101 ปล่อย

หรือ 1.0.101-090303 // ด้วยวันที่วางจำหน่ายฉันใช้มัน