คำถามติดแท็ก semantic-versioning

ในhttp://semver.org/ - ซึ่งในการรับรู้ของฉันดูเหมือนจะเป็นแบบแผนที่ใช้กันอย่างแพร่หลายในการกำหนดเวอร์ชัน - ขอแนะนำให้เพิ่มหมายเลขเวอร์ชันหลักเมื่อมีการแนะนำการเปลี่ยนแปลงที่แบ่ง / แก้ไข API มีสถานการณ์ที่เกี่ยวข้องสองสถานการณ์ที่ฉันไม่เห็นวิธีใช้แนวทางนี้แม้ว่า: จะเกิดอะไรขึ้นถ้ารหัสของฉันไม่มี API ใด ๆ ฉันควรรุ่นรหัสของฉันได้อย่างไร จะเกิดอะไรขึ้นถ้ารหัสของฉันเริ่มเสนอ API ในช่วงท้ายของการพัฒนา

42 semantic-versioning 

ผมได้อธิบายที่เสนอสร้างระบบ (Gradle / Artifactory / เจนกินส์ / Chef) ให้เป็นหนึ่งในสถาปนิกอาวุโสของเราและเขาได้แสดงความคิดเห็นกับฉันว่าฉันเรียงลำดับของการไม่เห็นด้วย แต่ผมไม่ได้มีประสบการณ์มากพอที่จะจริงๆชั่งน้ำหนักใน โครงการนี้สร้างไลบรารี Java (JAR) เป็นสิ่งประดิษฐ์ที่ทีมอื่นนำมาใช้ซ้ำ สำหรับการกำหนดเวอร์ชันฉันต้องการใช้ความหมายของ: <major>.<minor>.<patch> โดยที่patchระบุถึงการแก้ไขบั๊ก / ฉุกเฉินminorระบุรีลีสที่เข้ากันได้แบบย้อนหลังและmajorบ่งชี้ถึงการปรับเปลี่ยนขนาดใหญ่ของ API และ / หรือการเปลี่ยนแปลงที่เข้ากันไม่ได้ด้านหลัง ตราบใดที่การส่งมอบตรงนี้คือสิ่งที่ฉันต้องการ: นักพัฒนาให้รหัสบางส่วน; สิ่งนี้ทริกเกอร์การสร้างสภาพแวดล้อม QA / TEST การทดสอบบางอย่างถูกเรียกใช้ (บางแบบอัตโนมัติและแบบทดสอบด้วยตนเอง) หากการทดสอบทั้งหมดผ่านไปแล้วบิลด์โปรดักชั่นจะเผยแพร่ JAR ไปยัง repo ภายในองค์กรของเรา ณ จุดนี้ JAR ควรได้รับการกำหนดเวอร์ชันอย่างถูกต้องและความคิดของฉันคือการใช้สิ่งbuild.numberที่สร้างขึ้นโดยอัตโนมัติและจัดทำโดยเครื่องมือ CI ของเราเพื่อทำหน้าที่เป็นหมายเลขโปรแกรมแก้ไข ดังนั้นการกำหนดเวอร์ชันจะเป็น: <major>.<minor>.<build.number> อีกครั้งที่build.numberมีให้โดยเครื่องมือ CI สถาปนิกปฏิเสธสิ่งนี้โดยบอกว่าการใช้หมายเลขการสร้าง CI นั้นเป็น "การละเมิด" …

35 continuous-integration  versioning  builds  continuous-delivery  semantic-versioning 

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

30 programming-practices  git  semantic-versioning  tagging 

ฉันไม่ได้เรียนรู้การเขียนโปรแกรมที่โรงเรียนและฉันไม่ได้ทำงานในฐานะนักพัฒนา (มืออาชีพ) ดังนั้นพื้นฐานมากมายจึงไม่ค่อยชัดเจนสำหรับฉัน คำถามนี้พยายามที่จะอธิบายอย่างใดอย่างหนึ่ง ตอนนี้ขอสมมติว่าผมมีปัญหา#1, #2และ#3ในประเด็นการติดตามของฉันที่มีการกำหนดให้การแก้ไข / ปรับปรุงสำหรับรุ่น1.0.0และว่าที่ผ่านมา (มีเสถียรภาพ) 0.9.0เวอร์ชันคือ ฉันควรเพิ่มรุ่นเป็นเมื่อ1.0.0ใด เมื่อใดก) ปัญหาข้อใดข้อหนึ่งที่กล่าวข้างต้นถูกปิดหรือข) เมื่อปัญหาทั้งหมดที่เกี่ยวข้องกับรุ่น1.0ถูกปิด? วิธีไหนที่ถูกต้องที่จะทำ? และโดยวิธีที่ถูกต้องฉันหมายถึงสิ่งที่ใช้ในอุตสาหกรรมในปัจจุบัน

23 versioning  semantic-versioning 

ฉันกำลังจัดการห้องสมุดซึ่งมีจำนวนมากของการใช้งานของประชาชนและผมมีคำถามเกี่ยวกับความหมายเวอร์ชัน ฉันต้องการ refactor หนึ่งส่วนที่สำคัญพอสมควรของห้องสมุดซึ่งถูกนำไปใช้อย่างไม่ถูกต้อง - และถูกนำไปใช้อย่างไม่ถูกต้อง แต่การทำเช่นนี้จะหมายถึงการเปลี่ยนแปลง API สาธารณะซึ่งเป็นการตัดสินใจที่สำคัญ การเปลี่ยนแปลงที่ฉันต้องการทำให้หมุนรอบวิธีใช้ตัววนซ้ำ ขณะนี้ผู้ใช้ต้องทำสิ่งนี้: while ($element = $iterator->next()) { // ... } ซึ่งไม่ถูกต้องอย่างน้อยใน PHP พื้นเมืองอินเตอร์เฟซ Iterator ฉันต้องการแทนที่ด้วยสิ่งนี้: while ($iterator->valid()) { $element = $iterator->current(); // ... $iterator->next(); } ซึ่งคล้ายกับ: foreach ($iterator as $element) { // ... } หากคุณดูที่คู่มือของ Tom เกี่ยวกับการกำหนดเวอร์ชันแบบ semantic เขาระบุไว้อย่างชัดเจนว่าการเปลี่ยนแปลงใด ๆ กับ …

18 versioning  release-management  semantic-versioning 

ฉันเริ่มงานเป็นโปรแกรมเมอร์รุ่นพี่เมื่อไม่กี่เดือนที่ผ่านมา ระบบที่เรากำลังดำเนินการอยู่ได้รับการผลิตเป็นเวลา ~ 2 ปี ฉันไม่ได้เกี่ยวข้องกับการขอร้องของระบบและการออกแบบ สิ่งหนึ่งที่ฉันสังเกตเห็นได้คือรุ่นหลักของระบบนั้นมีอยู่แล้ว 11.YZ จากประสบการณ์ของฉันที่ทำงานกับระบบและไลบรารีอื่น ๆ ฉันไม่จำการเห็นผลิตภัณฑ์เวอร์ชันหลักกระแทกอย่างรวดเร็ว มีผลิตภัณฑ์ที่มีมานานหลายปีใน 1.XY และยังคงได้รับคุณสมบัติและแก้ไขข้อบกพร่อง สมมติว่าการใช้เวอร์ชันเชิงความหมายถูกต้องหรือไม่นี่บ่งชี้ว่าระบบได้รับการออกแบบไม่ดีเนื่องจากทำให้เกิดการเปลี่ยนแปลงครั้งใหญ่เกือบทุกสี่เดือนหรือไม่

16 versioning  semantic-versioning 

ตัวอย่างทั้งหมดของการกำหนดเวอร์ชันทางความหมายที่ฉันเห็นแสดงส่วนประกอบที่ใช้งานอยู่ 3 รายการ ไม่เกิน 2 จุดอักขระ ที่$DAYJOBเราใช้ 4 องค์ประกอบในหมายเลขรุ่นของเรา: 5.0.1.2 การกำหนดเวอร์ชันแบบ Semantic อนุญาตสำหรับสิ่งนี้หรือไม่ และในฐานะที่เป็นคำถามที่อยู่ในระดับที่สูงขึ้นและมีเหตุผลมากขึ้น ฉันเริ่มคิดว่าอาจเป็นความคิดที่ดีที่จะบังคับใช้การกำหนดเวอร์ชันแบบ semantic แต่ท้ายที่สุดเอนทิตีเช่น PCI จะแทนที่ ฉันควรจะชี้แจงความคิดเห็น PCI ของฉัน ปัญหาคือการตรวจสอบและมีผลต่อต้นทุนเมื่อองค์ประกอบหลักและรองเปลี่ยนไม่จำเป็นต้องเป็นคุณสมบัติใหม่จริง ตัวอย่างเช่นหากมีการแนะนำคุณลักษณะที่เกี่ยวข้องกับการชำระเงินเราจะชนหมายเลขรองสำหรับ PCI แต่ถ้าเราเพิ่มฟีเจอร์ใหม่ที่เกี่ยวข้องกับสิ่งที่อยู่ใน gui มันก็ไม่ได้ เฉพาะการแก้ไขแพทช์ ดังนั้นในกรณีนี้เราไม่ได้พูดจริง ๆ ในฐานะผู้พัฒนาเนื่องจากมีคนอื่นทำการตัดสินใจเหล่านั้น

16 versioning  semantic-versioning  pci 

คำถาม : เป็นวิธีที่เหมาะสมในการแก้ไขข้อผิดพลาดที่คิดว่าผู้ใช้ปลายทางเป็นคุณสมบัติคืออะไร? การทำอย่างละเอียด : ฉันคาดเดาว่าหากมีผู้ใช้จำนวนมากคาดหวังว่ามันจะเป็นฟีเจอร์มันควรจะอยู่ที่ "ไม่ได้ผสม" หรือ "คงที่" เพื่อให้มีเสถียรภาพมากขึ้นหรือไม่ อย่างไรก็ตามจะเกิดอะไรขึ้นถ้าผู้ใช้จำนวนน้อยมากคาดหวังว่ามันจะเป็นคุณสมบัติ ... พูด 0.1% หรือ 1% และข้อผิดพลาดนี้จะต้องได้รับการแก้ไข ในทางทฤษฎีเนื่องจากนี่เป็นการแก้ไขบั๊กเล็กน้อยจึงสามารถมีคุณสมบัติเป็น PATCH โดยพิจารณาจากการกำหนดเวอร์ชันแบบ semantic: xyZ อย่างไรก็ตามเนื่องจากความเข้ากันได้แบบย้อนกลับ มันจะยังคงมีคุณสมบัติเป็นแพทช์ (เพราะมันไม่ได้มีวัตถุประสงค์เพื่อเป็นคุณสมบัติ) ตราบใดที่มันเป็นเอกสาร? แก้ไข: ในกรณีเฉพาะนี้มันเป็นข้อผิดพลาดใน API ของห้องสมุดที่ใช้ภายในที่นักพัฒนาอื่นใช้

15 versioning  bug  features  semantic-versioning