xyz> xyz-beta (또는 alpha, rc 등)의 증분 RPM 패키지 버전“번호”

몇 가지 다른 소프트웨어 버전의 RPM 패키지를 게시하기 위해 "업그레이드"로 간주되는 "숫자"버전을 지정하고 (예 : 순서대로) 여러 시험판 버전의 차별화를 포함하는 방법을 찾고 있습니다 ) : "2.4.0 알파 1", "2.4.0 알파 2", "2.4.0 알파 3", "2.4.0 베타 1", "2.4.0 베타 2", "2.4.0 릴리스 후보", "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"이후에 고려되는 "릴리스 후보"를 제외하고 작동합니다. ".

내가 고려한 대안은 RPM 버전 번호의 "epoch :"섹션을 사용하는 것입니다 (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)에 실패합니다. rpm이 이전 버전으로 간주되므로 0 "및 2.3.2의 시스템은 2.4.0으로"업그레이드 "할 수 없습니다. 이 경우 yum / zypper / etc는 2.4.0으로의 업그레이드를 거부하므로 문제가 있습니다.

이를 달성하기 위해 어떤 버전 번호를 사용할 수 있으며 RPM이 항상 버전 번호를 순서대로 고려하는지 확인하십시오. 또는 버전 번호가 아닌 경우 RPM 패키지의 다른 메커니즘은 무엇입니까?

참고 1 : 사양 파일의 "릴리스 :"필드를 원래 목적 (패키지 변경을 포함하여 동일한 버전의 패키지 소프트웨어에 대한 패키지 릴리스)으로 유지하려고합니다.

참고 2 : 이것은 RHEL / CentOS 6 및 SLES 11과 같은 주요 배포판의 현재 프로덕션 버전에서 작동합니다. 그러나 rpm 재 컴파일을 포함하지 않는 한 솔루션에 관심이 있습니다!

참고 3 : 데비안 유사 시스템에서 dpkg는 버전 번호에 "~"(물결표) 문자 인 특수 구성 요소를 사용합니다. 이로 인해 dpkg는 접미어를 "음수"순서로 계산하므로 "2.4.0 ~ anything"이 "2.4.0"앞에 오게됩니다. 그런 다음 "~"뒤에 일반 순서가 적용되므로 "알파"가 알파벳순으로 "베타"앞에 오므로 "2.4.0 ~ 알파 1"이 "2.4.0 ~ 베타 1"앞에옵니다. RPM 패키지에 동일한 체계를 사용하려고하지는 않습니다 (그와 동등한 것이 존재하지 않을 것이라고 확신합니다). 이것은 단지 FYI입니다.

공식 RPM 지침은 이 작업을 수행하는 방법을 이야기하고, 링크 예 페이지 . 다음은 세 가지 레벨의 시험판 (a, b, rc)을 사용하는 매우 일반적인 버전 관리 체계를 사용하는 방법의 예입니다 (rpm은 불행히도 지원하기가 약간 복잡합니다).

• 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시작하십시오 . 최종 릴리스 에는 영숫자 태그 를 전혀 사용하지 않습니다 .Release0.alphabetafinal

데비안 스타일의 틸드 버전 관리를 지원하는 RPM은 신뢰할 수 없습니다. 여러 배포판에서이 기능을 비활성화합니다.

나는 알파 / 베타 구별의 팬이 아닙니다. 릴리스 된 코드와 릴리스되지 않은 코드가 있습니다.

방법 : 지속적인 통합 시스템을 갖춘 major.minor.build를 선호합니다 (JenkinsCI 참조). 빌드 정수는 재설정되지 않습니다. 작은 버전 번호 변경은 이전 버전과 호환되는 변경을위한 것입니다. 주요 숫자 변경은 큰 거래입니다.

마케팅에서 "빌드"가 큰 정수가 아닌 경우 릴리스 된 빌드에서만 마케팅을 위해 부 번호를 한 번 증가한 다음 엔지니어링으로 갈 때 다시 부수를 증가시킬 수 있습니다.

비슷한 문제에 부딪 쳤고 RedHat, Debian, Python 패키지와 Ruby gem의 개정판을 비교하여 제품군 번호를 통합해야했으며,이 경우 각 경우에 "보다 큼"과 "보다 작음"을 평가하는 데 도움이되었습니다.

이것은 1.3.0.post0.dev20180213210433과 YMMV 1.3.0을 비교합니다.

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

데비안의 경우 :

$ 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