จะใช้อะไรเป็นรุ่นเริ่มต้น? [ปิด]


122

ฉันมักจะเริ่มโครงการด้วยเวอร์ชัน 1.0.0 ทันทีที่ฉันมีของบางอย่างเข้าด้วยกันฉันจะปล่อยมันเป็น 1.0.0 และไปต่อด้วย 1.1.0

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

คุณจะแนะนำให้ทำอะไร เริ่มต้นด้วย 1.0.0 หรือ 0.1.0?

หมายเลขสุดท้ายสำหรับการเผยแพร่ bugfix โดยวิธีการเท่านั้น คุณคิดว่า 1.0.0 ของฉันเป็น 1.0 และ 0.1.0 เท่ากับ 0.1 นั้นง่ายกว่าสำหรับคุณ


1
ฉันเพิ่งค้นพบเกี่ยวกับ "การกำหนดเวอร์ชันความหมาย" ( semver.org ) นั่นเป็นสิ่งที่ฉันอยากทำมาก อย่างไรก็ตามฉันไม่ได้สร้าง API และกำลังพูดถึง API ดังนั้นคำแนะนำ 1.0.0 จึงใช้ไม่ได้จริงๆ
Noarth


คำตอบ:


-24

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

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

หากเป็นการโทรของคุณให้ทำทุกอย่างที่ดีที่สุดสำหรับคุณ ฉันมีปัญหาบางอย่างกับเวอร์ชันก่อน 1.0 ดังนั้นฉันจึงเริ่มต้นด้วยสิ่งนั้น


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

225

มาตรฐานSemantic Versioning 2.0.0กล่าวว่า:

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

ปรับจาก 0.3.0 เป็น 1.0.0 ได้ มันก็โอเคอย่างสมบูรณ์ที่จะอยู่ที่ 0.23.0 การเริ่มต้นที่ 0.4.0 นั้นค่อนข้างมองไม่เห็นเนื่องจากมีการเผยแพร่เวอร์ชันก่อนหน้านี้

นอกจากนี้โปรดทราบว่า0.y.zถูกเก็บไว้เพื่อการทำซ้ำอย่างรวดเร็วเพื่อให้การพัฒนาครั้งแรก (และด้วยเหตุนี้การเปลี่ยนแปลงมากมาย) จะไม่ทำให้คุณรู้สึกโง่ ๆ เช่น 142.6.0 แทนที่จะชนรุ่นหลักให้ชนรุ่นรองในทุก ๆ การเปลี่ยนแปลงจนกว่าคุณจะปล่อย 1.0.0:

เวอร์ชันหลักศูนย์ (0.yz) ใช้สำหรับการพัฒนาครั้งแรก ทุกอย่างอาจเปลี่ยนแปลงได้ตลอดเวลา API สาธารณะไม่ควรถือว่าเสถียร


นี่ต้องเป็นคำตอบที่ยอมรับได้ ไม่เคยเห็นคำตอบที่มี 16 โหวตเป็นคำตอบที่ได้รับการยอมรับ
Nader Ghanbari

มีข้อผิดพลาดหากคุณใช้ npm หากคุณเริ่มต้นด้วย 0 เครื่องหมายคาเร็ต "^" ใน package.json จะทำงานแตกต่างกัน docs.npmjs.com/misc/semver#caret-ranges-123-025-004คุณสามารถใช้ 0.x แทน ^ 0 ในแพ็คเกจ json สำหรับสถานการณ์นี้ ดังนั้น 1.x จึงง่ายกว่าเล็กน้อยในการเริ่มต้นและใช้งาน
แซม

9

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

โปรแกรมเมอร์ที่ยอดเยี่ยมได้ใช้ระบบการกำหนดหมายเลขเวอร์ชันเป็นเรื่องตลกในท้องถิ่น ตัวอย่าง (Wikipedia):

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

สำหรับ METAFONT:

Metafont มีระบบการกำหนดเวอร์ชันที่คล้ายกับของ TeX โดยที่ตัวเลขจะเข้าใกล้ e ในการแก้ไขแต่ละครั้งโดยไม่มีอาการ

สุดท้ายไม่ใช่หมายเลขเวอร์ชัน แต่ที่น่าสนใจไม่แพ้กันคือการเสนอขายหุ้นต่อประชาชนทั่วไป (IPO) ของ Google ได้ยื่นต่อสำนักงาน ก.ล.ต. เพื่อระดมทุน 2,718,281,828 ดอลลาร์ (สังเกตว่า ~ 2.718 281828)

ประเด็นของฉันคืออย่ารู้สึกว่าต้องทำตามฝูงชน มีความคิดสร้างสรรค์และสม่ำเสมอ


6

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

และฉันชอบวิธีที่ลินุกซ์มีเลขคี่สำหรับเวอร์ชันที่ไม่เสถียรและเลขคู่สำหรับเวอร์ชันเสถียร


1

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

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


3
นั่นหมายความว่าคุณสามารถไปได้ไกลถึง 0.9.0 เท่านั้น แต่ฉันรู้หลายโครงการที่ดำเนินไปเช่น 0.25.0
Noarth

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

1

เมื่อเลือกหมายเลขเวอร์ชันสำหรับnpmแพ็กเกจโปรดทราบว่าสำหรับการอ้างอิงที่แสดงในpackage.json ช่วง semverจะไม่ทำงานต่ำกว่า v1.0.0 นั่นคือ,

"dependencies": {
    "my-package": "^0.5"
}

เทียบเท่ากับ

"dependencies": {
    "my-package": "0.5"
}

หากคุณต้องการใช้ช่วง semver หรือต้องการให้คนอื่นใช้คุณอาจต้องการเริ่มต้นด้วย 1.0.0


น่าสนใจ คุณมีข้อมูลเพิ่มเติมเกี่ยวกับสาเหตุ (หรือที่ใด) ช่วง Semver ไม่ทำงานต่ำกว่า 1.0.0 หรือไม่ เนื่องจากมีแพคเกจค่อนข้างบางใช้0.0.xในรีจิสทรี NPM
Remi

ฉันไม่รู้ว่าทำไมคน npm ถึงตัดสินใจแบบนั้นหรือสร้างที่ไหนในระบบ npm / สิ่งที่ต้องเปลี่ยนเพื่อรองรับช่วง semver สำหรับเวอร์ชันที่น้อยกว่า 1 ฉันก็สนใจที่จะรู้เช่นกัน!
henry

3
พวกเขาได้ตัดสินใจว่าเพราะ^หมายถึง "เข้ากันได้กับรุ่น" รายละเอียดเพิ่มเติมที่นี่ ใน semver 0.y.zมีไว้สำหรับการพัฒนาครั้งแรกและการเปลี่ยนแปลงใด ๆ ในyหรือzสามารถย้อนกลับเข้ากันไม่ได้ ในตัวอย่างของคุณ^0.5 := 0.5 := 0.5.xจึงเป็นช่วง หากช่วง0.y.zคาเร็ตใช้ไม่ได้สำหรับคุณในช่วงนี้คุณสามารถใช้ตัวเปรียบเทียบขีดกลาง x และช่วงเครื่องหมายทิลเดนอกเหนือจากช่วงคาเร็ตได้
dosentmatter

0

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

หากคุณกังวลว่าเวอร์ชัน 0.6.5 มีวงแหวนที่ไม่สมบูรณ์คุณอาจต้องการวางตลาดภายใต้เวอร์ชัน 1.0 หมายเลขเวอร์ชันทางการตลาดของคุณไม่จำเป็นต้องตรงกับหมายเลขเวอร์ชันภายในของคุณ ตัวอย่างเช่นหมายเลขเวอร์ชันของ Windows 7 คือ 6.1

ความชอบส่วนตัวของฉันคือเริ่มจาก 0.1.0 และไปจากที่นั่น


0

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

ด้วยโปรเจ็กต์ทีมใครก็ตามที่วางแท็กเวอร์ชันแรกจะได้ตัดสินใจ :)


0

0.1.0 คือสิ่งที่ฉันเริ่มต้นและเลื่อนขึ้นจากที่นั่น นี่คือสิ่งที่ฉันปรับให้เข้ากับ Xploration By Adrian แม้ว่าในช่วงปีแรก ๆ ฉันจะใช้งานเป็นระยะ ๆ และใช้ 1.0.0, 0.0.1 และอื่น ๆ อีกเล็กน้อย แต่ฉันขอแนะนำให้เริ่มต้นที่ 0.1.0 และไปจากที่นั่น

ต่อ Semver จอง a และ c ใน abc สำหรับ A. คุณเผยแพร่อย่างเป็นทางการครั้งแรกและ C. แก้ไขข้อบกพร่องและแพตช์ เนื่องจากโดยทั่วไปแล้วเวอร์ชันหลักจะแบ่งรหัสรุ่นเก่าออกไป และแพทช์เพียงแค่แก้ไขข้อบกพร่อง นี่เป็นความชอบส่วนตัวทั้งหมด 0.99.0 ไม่ได้หมายความว่าคุณต้องไปที่ 1.0.0 ฯลฯ ฉันเคยเห็นบางส่วนที่ไปถึง 0.218.42


-1

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

อาจจะทำตามอย่างเช่น: First # คือรุ่นนายกเทศมนตรี, Second # เป็นรุ่นเดียวกันกับนายกเทศมนตรีที่มีการเพิ่มคุณสมบัติบางอย่างและ Third # เป็นรุ่นเดียวกันกับนายกเทศมนตรีโดยมีคุณสมบัติเหมือนกัน แต่มีข้อบกพร่องคงที่หรือเพิ่มการเปลี่ยนแปลงเล็กน้อย (แต่มีนัยสำคัญเพียงพอ)

1.3.2 => รุ่นที่ 1 พร้อมคุณสมบัติเพิ่มเติมและแก้ไขข้อบกพร่องบางอย่าง

อย่างไรก็ตามสำหรับผู้ใช้ขั้นสุดท้ายบางคนมักใช้ตัวเลขจำนวนมากสำหรับการเผยแพร่ขั้นสุดท้าย

ตัวอย่างเช่น Corel 8 สำหรับ 8.0.0, 8.0.1, 8.2.2 ฯลฯ Corel 9 สำหรับ 9.0.0 ... ฯลฯ

และส่วนใหญ่จะเกี่ยวกับกลยุทธ์ทางการตลาดเช่น Corel X5 แทนที่จะเป็น Corel 15.0.2 เป็นต้น

ฉันจะบอกว่ามันขึ้นอยู่กับว่าหมายเลขเวอร์ชันสำหรับคุณหรือสำหรับลูกค้า


-4

เริ่มต้นด้วย 0.0.0 และไปต่อจากที่นั่น


4
นั่นหมายความว่าคุณจะทำการรีลีส 0.0.0 จริงหรือ? ฉันเริ่มต้นด้วยหมายเลขแรกที่ฉันจะปล่อย
Noarth

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