RPM แพ็กเกจเวอร์ชันเสริมสำหรับ“ ตัวเลข” สำหรับ xyz> xyz-beta (หรืออัลฟ่า, rc ฯลฯ )

ในการเผยแพร่แพ็คเกจ RPM ของซอฟต์แวร์บางเวอร์ชันที่แตกต่างกันฉันกำลังมองหาวิธีการระบุ "หมายเลข" รุ่นที่ถือว่าเป็น "อัปเกรด" และรวมถึงความแตกต่างของรุ่นก่อนวางจำหน่ายหลายรุ่นเช่น (ตามลำดับ ): "2.4.0 alpha 1", "2.4.0 alpha 2", "2.4.0 alpha 3", "2.4.0 beta 1", "2.4.0 alpha 1", "2.4.0 alpha 2", "2.4.0 alpha 2", "2.4.0 final", "2.4.1", "2.4.2" ฯลฯ

ปัญหาหลักที่ฉันมีคือ RPM เห็นว่า "2.4.0" มาก่อน "2.4.0.alpha1" ดังนั้นฉันไม่สามารถเพิ่มส่วนต่อท้ายที่ท้ายของหมายเลขเวอร์ชั่นสุดท้ายได้

ฉันสามารถลอง "2.4.0.alpha1", "2.4.0.beta1", "2.4.0.final" ซึ่งจะทำงานได้ยกเว้น "ผู้สมัครรุ่น" ที่จะได้รับการพิจารณาช้ากว่า "2.4.0.final "

ทางเลือกอื่นที่ฉันพิจารณาใช้ส่วน "epoch:" ของหมายเลขเวอร์ชัน RPM (ส่วนนำหน้า epoch: ถูกพิจารณาก่อนหมายเลขเวอร์ชันหลักเพื่อให้ "1: 2.4.0" เป็นจริงก่อนหน้า "2: 1.0.0") . ด้วยการวางการประทับเวลาลงในฟิลด์ epoch: ทุกเวอร์ชันจะได้รับคำสั่งตามที่ RPM คาดหวังเนื่องจากเวอร์ชันของพวกเขาจะเพิ่มขึ้นตามเวลา อย่างไรก็ตามสิ่งนี้จะล้มเหลวเมื่อมีการออกรุ่นใหม่ ๆ ในรุ่นใหญ่หลายรุ่นในเวลาเดียวกัน (ตัวอย่างเช่น 2.3.2 ออกใช้หลังจาก 2.4.0 แต่รุ่นสำหรับ RPM นั้นเป็น "20121003: 2.3.2" และ "20120928: 2.4 0 "และระบบใน 2.3.2 ไม่สามารถรับ" อัปเกรด "เป็น 2.4.0 ได้เนื่องจาก rpm มองว่าเป็นรุ่นเก่ากว่า) ในกรณีนี้ yum / zypper / etc ปฏิเสธที่จะอัปเกรดเป็น 2.4.0 ดังนั้นปัญหาของฉัน

ฉันสามารถใช้หมายเลขเวอร์ชันใดเพื่อให้บรรลุสิ่งนี้และตรวจสอบให้แน่ใจว่า RPM พิจารณาหมายเลขรุ่นตามลำดับเสมอ หรือหากไม่ใช่หมายเลขรุ่นกลไกอื่น ๆ ในบรรจุภัณฑ์ RPM?

หมายเหตุ 1: ฉันต้องการเก็บฟิลด์ "Release:" ของไฟล์ข้อมูลจำเพาะไว้เพื่อจุดประสงค์ดั้งเดิม (มีการออกแพ็คเกจหลายครั้งรวมถึงการเปลี่ยนแปลงบรรจุภัณฑ์สำหรับซอฟต์แวร์รุ่นเดียวกัน)

หมายเหตุ 2: สิ่งนี้ควรใช้กับเวอร์ชันที่ใช้งานจริงในปัจจุบันของการแจกแจงหลักเช่น RHEL / CentOS 6 และ SLES 11 แต่ฉันสนใจวิธีแก้ไขปัญหาที่ไม่เช่นนั้นตราบใดที่พวกเขาไม่ได้ทำการคอมไพล์รอบต่อนาที!

หมายเหตุ 3: บนระบบที่คล้ายกับเดเบียน dpkg ใช้คอมโพเนนต์พิเศษในหมายเลขเวอร์ชันซึ่งเป็นอักขระ "~" (tilde) สิ่งนี้ทำให้ dpkg นับส่วนต่อท้ายเป็นการสั่ง "ลบ" ดังนั้น "2.4.0 ~ อะไรก็ได้" จะมาก่อน "2.4.0" จากนั้นการสั่งซื้อปกติจะใช้หลังจาก "~" ดังนั้น "2.4.0 ~ alpha1" มาก่อน "2.4.0 ~ beta1" เพราะ "alpha" มาก่อน "เบต้า" ตามลำดับตัวอักษร ฉันไม่ได้ต้องการใช้รูปแบบเดียวกันสำหรับแพ็คเกจ RPM (ฉันค่อนข้างแน่ใจว่าไม่มีสิ่งเทียบเท่ากัน) ดังนั้นนี่เป็นเพียง FYI

แนวทางรอบต่อนาทีอย่างเป็นทางการบอกวิธีการทำเช่นนี้และเชื่อมโยงไปยังหน้าตัวอย่าง นี่คือตัวอย่างของวิธีที่คุณจะทำงานกับโครงร่างการกำหนดรุ่นทั่วไปที่ใช้การปล่อยล่วงหน้าสามระดับ (a, b, rc) (ซึ่งรอบต่อนาทีน่าเสียดายที่ทำให้ซับซ้อนเล็กน้อยเพื่อรองรับ):

• 1.0.0a1 -> 1.0.0-0.1.a1
• 1.0.0b1 -> 1.0.0-0.1.b1
• 1.0.0b2 -> 1.0.0-0.1.b2
• 1.0.0b2, รุ่นที่สอง (บรรจุภัณฑ์ปรับแต่งที่ 1.0.0b2) -> 1.0.0-0.2.b2
• 1.0.0rc1 -> 1.0.0-0.1.rc1
• 1.0.0 -> 1.0.0-1
• 1.0.1a1 -> 1.0.1-0.1.a1
• 1.0.1 -> 1.0.1-1

Fedora มีชุดของแนวทางสำหรับการตั้งค่ารุ่น / จำนวนการเปิดตัวของแพคเกจก่อนวางจำหน่าย โดยทั่วไปคุณใช้หมายเลขรุ่นของสิ่งที่จะเป็นรุ่นสุดท้ายในVersionและเริ่มต้นReleaseจำนวนที่มี0.เป็นจำนวนที่เพิ่มขึ้นและจากนั้นalpha, betaหรืออะไรก็ตาม คุณจะไม่ใช้แท็กตัวอักษรและตัวเลขfinalสำหรับรุ่นสุดท้ายเลย

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

ฉันไม่ใช่แฟนของความแตกต่างของอัลฟา / เบต้า มีรหัสเผยแพร่และรหัสที่ยังไม่เผยแพร่

ฉันจะทำอย่างไร: ฉันชอบ major.minor.build ด้วยระบบการรวมอย่างต่อเนื่อง (ดู JenkinsCI) Build จำนวนเต็มไม่เคยถูกรีเซ็ต การเปลี่ยนแปลงหมายเลขรุ่นรองสำหรับการเปลี่ยนแปลงที่เข้ากันได้ย้อนหลัง การเปลี่ยนแปลงจำนวนมากเป็นเรื่องใหญ่

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

ฉันชนเป็นปัญหาที่คล้ายกันและฉันต้องเปรียบเทียบการแก้ไขระหว่างแพ็คเกจ RedHat, Debian, Python และ Ruby gems เพื่อรวมหมายเลขชุดและสิ่งนี้ช่วยให้ฉันประเมิน "มากกว่า" และ "น้อยกว่า" ในแต่ละกรณี:

นี่คือการเปรียบเทียบ 1.3.0.post0.dev20180213210433 ถึง 1.3.0, YMMV

สำหรับ Red Hat (ขอบคุณhttps://utcc.utoronto.ca/~cks/space/blog/linux/RPMShellVersionComparison )

docker run -ti centos:7
yum install rpmdevtools.noarch
rpmdev-vercmp "1.3.0" "1.3.0.post0.dev20180213210433" 
1.3.0 < 1.3.0.post0.dev20180213210433

สำหรับ Debian:

$ dpkg --compare-versions 1.3.0 gt 1.3.0.post0.dev20180213210433 ; echo $?
1  # false
$ dpkg --compare-versions 1.3.0 lt 1.3.0.post0.dev20180213210433 ; echo $?
0  # true

สำหรับงูหลาม

>>> from pkg_resources import parse_version
>>> parse_version("1.3.0") > parse_version("1.3.0.post0.dev20180213210433")
False
>>> parse_version("1.3.0") < parse_version("1.3.0.post0.dev20180213210433")
True

สำหรับทับทิม

irb(main):001:0> Gem::Version.new("1.3.0") > Gem::Version.new("1.3.0.post0.dev20180213210433")
=> true
irb(main):002:0> Gem::Version.new("1.3.0") < Gem::Version.new("1.3.0.post0.dev20180213210433")
=> false

ตั้งแต่เวอร์ชัน 4.10.0, RPM รองรับการกำหนดหมายเลขตัวหนอนแบบ dpkg อย่างเป็นทางการที่กล่าวถึงในคำถาม

https://rpm.org/wiki/Releases/4.10.0