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

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

140 version-control  git  github  versioning  branching 

องค์กรของฉันกำลังพิจารณาย้ายจาก SVN เป็น Git การโต้แย้งหนึ่งเรื่องการเคลื่อนย้ายมีดังนี้: เราจะทำเวอร์ชันอย่างไร เรามีการเผยแพร่ SDK ตามแพลตฟอร์ม NetBeans เนื่องจากการแก้ไข SVN เป็นตัวเลขอย่างง่ายเราจึงสามารถใช้พวกเขาเพื่อขยายหมายเลขรุ่นของปลั๊กอินและการสร้าง SDK ของเรา เราจะจัดการกับสิ่งนี้ได้อย่างไรเมื่อเราย้ายไปที่ Git การแก้ปัญหาที่เป็นไปได้: การใช้หมายเลขบิลด์จากฮัดสัน (ปัญหา: คุณต้องตรวจสอบฮัดสันเพื่อเชื่อมโยงกับเวอร์ชัน Git จริง) upping เวอร์ชันด้วยตนเองสำหรับทุกคืนและมีเสถียรภาพ (ปัญหา: เส้นโค้งการเรียนรู้ข้อผิดพลาดของมนุษย์) หากคนอื่นพบปัญหาที่คล้ายกันและแก้ไขมันเรายินดีที่จะได้ยินว่า

131 version-control  git  svn  builds  versioning 

ข้อตกลงการตั้งชื่อเวอร์ชันต่างกันเหมาะสมกับโครงการที่แตกต่างกันหรือไม่ คุณใช้อะไรและทำไม โดยส่วนตัวแล้วฉันชอบหมายเลขบิลด์เป็นเลขฐานสิบหก (เช่น 11BCF) ซึ่งควรเพิ่มขึ้นเป็นประจำ จากนั้นสำหรับลูกค้าจะมีหมายเลขเวอร์ชัน 3 หลักอย่างง่ายคือ 1.1.3 1.2.3 (11BCF) <- Build number, should correspond with a revision in source control ^ ^ ^ | | | | | +--- Minor bugs, spelling mistakes, etc. | +----- Minor features, major bug fixes, etc. +------- Major version, UX changes, …

107 project-management  development-process  naming  versioning 

ฉันเห็นว่า Java 1.2 รู้จักกันในชื่อ Java 2 สนใจ "Java 1.x" และ "Java x" (เช่น "Java 1.6" และ "Java 6") อ้างถึง Java รุ่นเดียวกันหรือไม่ และถ้าใช่ทำไมต้องเป็นคู่นี้?

58 java  history  versioning  product-names 

สิ่งที่ฉันคิดเกี่ยวกับ Build Numbers คือเมื่อใดก็ตามที่สร้างบิลด์ใหม่ทุกคืนบิลด์ใหม่จะถูกสร้างและกำหนดให้กับบิลด์นั้น ดังนั้นสำหรับแอปพลิเคชันเวอร์ชัน 7.0 ของฉันบิลด์บิลด์ต่อคืนจะเป็น 7.0.1, 7.0.2 เป็นต้น มันเป็นอย่างนั้นเหรอ? ถ้าเช่นนั้นการใช้ REVISION หลังจากหมายเลขบิลด์คืออะไร? หรือว่าส่วนการปรับปรุงจะเพิ่มขึ้นหลังจากการสร้างทุกคืน? ฉันสับสนเล็กน้อยที่นี่ ... เราจะอ้างถึงยามค่ำคืนสร้างแต่ละเป็นBUILD ? รูปแบบที่กล่าวถึงที่นี่: AssemblyVersion - MSDN

55 builds  versioning 

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

46 versioning  continuous-integration 

นักพัฒนาซอฟต์แวร์โดยทั่วไปจะไม่ใช้วันที่เป็นหมายเลขเวอร์ชันแม้ว่ารูปแบบ YYYYMMDD (หรือความแปรปรวน) จะดูแข็งแกร่งพอที่จะใช้ มีอะไรผิดปกติกับโครงการนี้หรือไม่? หรือใช้กับซอฟต์แวร์ประเภท 'จำกัด ' เท่านั้น (เช่นการผลิตภายใน)

43 versioning 

ซ้ำได้: คุณใช้“ แบบแผนการตั้งชื่อเวอร์ชัน” อะไร คุณเปลี่ยนหมายเลขรุ่นหลัก / รอง / แพตช์ของคุณทันทีก่อนที่คุณจะวางจำหน่ายหรือหลังจากนั้น ตัวอย่าง: คุณเพิ่งปล่อย 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 ตามลำดับ

40 versioning 

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

35 web-applications  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 

หนึ่งในเหตุผลที่โปรแกรมเมอร์ชอบ SVN มากกว่า CVS คืออดีตยอมให้มีการปรมาณู สิ่งนี้หมายความว่า ?

34 svn  versioning  cvs 

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

23 versioning  semantic-versioning 

เวอร์ชันผลิตภัณฑ์เช่นv1.0.0.100ไม่เพียงแสดงถึงการผลิตซอฟต์แวร์ที่ไม่ซ้ำใคร แต่ช่วยระบุชุดคุณลักษณะและขั้นตอนการแก้ไขด่วนสำหรับผลิตภัณฑ์ดังกล่าว ตอนนี้ฉันเห็นสองวิธีในการรักษาแพ็กเกจ / build / ไบนารีเวอร์ชันสุดท้ายของผลิตภัณฑ์: การควบคุมเวอร์ชัน ไฟล์ที่เก็บหมายเลขรุ่น เซิร์ฟเวอร์การสร้างการรวมต่อเนื่อง (CI) จะมีสคริปต์เพื่อสร้างซอฟต์แวร์ที่ใช้หมายเลขรุ่นที่เช็คอินนี้เพื่อใช้กับทุกพื้นที่ของซอฟต์แวร์ที่ต้องการ (ไบนารีแพคเกจการติดตั้งหน้าช่วยเหลือเอกสาร ฯลฯ ) สภาพแวดล้อมและ / หรือสร้างพารามิเตอร์ สิ่งเหล่านี้ได้รับการดูแลรักษาไว้นอกการควบคุมเวอร์ชัน (เช่นไม่ได้เชื่อมโยงกับสแน็ปช็อต / แท็ก / สาขา) สคริปต์การสร้างกระจายและใช้หมายเลขในลักษณะเดียวกัน แต่พวกเขาเพิ่งได้รับค่าที่แตกต่างกัน (มันมีให้กับสคริปต์การสร้างแทนที่จะให้สคริปต์รู้ว่าจะรับได้ที่ไหนเทียบกับต้นไม้แหล่งที่มา) ปัญหาที่เกิดขึ้นกับวิธีแรกคือมันสามารถทำให้เกิดการผสมข้ามสาขาได้ยาก หากคุณยังคงรักษาซอฟต์แวร์รุ่นเดียวกันไว้ 2 ขนานคุณจะแก้ไขข้อขัดแย้งเมื่อรวมระหว่างการฉีดสองครั้งหากเวอร์ชันมีการเปลี่ยนแปลงทั้งคู่ตั้งแต่การรวมครั้งล่าสุด ปัญหาเกี่ยวกับวิธีการที่สองคือการกระทบยอด เมื่อคุณกลับไปที่การวางจำหน่าย 1 ปีที่ผ่านมาคุณจะพึ่งพาข้อมูลแท็กเพียงอย่างเดียวเพื่อระบุหมายเลขรุ่น ในทั้งสองกรณีอาจมีบางแง่มุมของหมายเลขเวอร์ชันที่ไม่ทราบก่อนสร้าง CI ตัวอย่างเช่นการสร้าง CI โดยทางโปรแกรมอาจใส่องค์ประกอบที่ 4 ซึ่งเป็นหมายเลขบิลด์อัตโนมัติ (เช่นบิลด์ที่ 140 ในสาขา) อาจเป็นหมายเลขการแก้ไขใน VCS วิธีที่ดีที่สุดในการติดตามหมายเลขเวอร์ชันของซอฟต์แวร์คืออะไร ควรรักษาชิ้นส่วน "รู้จัก" …

22 version-control  continuous-integration  versioning  release-management  continuous-delivery 

สมมติว่าคุณมีอินเทอร์เฟซIFoo: public interface IFoo { void Bar(string s); int Quux(object o); } ใน API รุ่นที่ 2 ของคุณคุณจะต้องเพิ่มวิธีGlargการในอินเทอร์เฟซนี้ คุณจะทำเช่นนั้นได้อย่างไรโดยไม่ทำลายผู้ใช้ API ที่มีอยู่และรักษาความเข้ากันได้ย้อนหลัง นี่คือจุดมุ่งหมายหลักที่. NET แต่สามารถนำไปใช้กับกรอบและภาษาอื่น ๆ เช่นกัน

22 versioning  interfaces 

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

21 version-control  versioning  branching  product-management