빠른 메이저 버전이 디자인이 좋지 않다는 증거가 있습니까?

16

몇 달 전에 주니어 프로그래머로 일을 시작했습니다. 우리가 작업하고있는 시스템은 ~ 2 년 동안 생산되었습니다. 나는 시스템과 디자인을 구걸하는 데 관여하지 않았습니다.

제가 주목 한 것은 시스템 메이저 버전은 이미 11입니다 .YZ 다른 시스템 및 라이브러리와 함께 일한 경험을 바탕으로, 메이저 버전을 빠르게 부딪히는 제품을 본 적이 있습니다. 1.XY 년 동안 수년간 사용 되어 왔지만 여전히 기능과 버그 수정을받은 제품이 있습니다 .

시맨틱 버전 관리 가 올바르게 사용 되었다고 가정하면 , 시스템이 거의 4 개월마다 주요 변경을 수행하기 때문에 시스템이 제대로 설계되지 않았 음을 나타 냅니까?

versioning semantic-versioning

— 사용자 367035
소스

2

그 주요한 변화는 높은 변화율을 정당화 할 수있는 충분한 이익 (과 이익)을 가져 오는지에 달려 있습니다.

— rwong

3

해당 버전 번호가 Semver를 사용하고 시스템에 다른 팀이나 조직이 의존하는 라이브러리 또는 다른 API가있는 경우이 높은 숫자는 안정적이고 확장 가능한 API 설계를 수행하는 데 문제가 있음을 의미합니다. 또한 비 호환성을 명확하게 전달하는 것이 중요하다는 것을 의미합니다. 다른 이름 (예 : 마케팅 이름, 응용 프로그램, 비 Semver 번호 등)의 경우이 번호는 의미가 없으므로 크게 무시해야합니다. 프로젝트에 대해 더 잘 알게되면 동료들에게 이것에 대해 물어보십시오.

— amon

3

@amon이 시스템은 REST 유사 API를 통해 시스템과 통신하는 공용 모바일 클라이언트와 내부적으로 사용됩니다. 버전 관리는 마케팅 버전이 아니라 언급 한대로 Semver입니다.

— user367035

숫자는 중요하지 않지만 버전 식별자에 Windows NT, Windows ME 또는 XP 또는 실제로 Windows와 같은 귀여운 약어가 포함되어 있으면 의심됩니다.

— John Wu

1

@ JohnWu : 질문은 숫자에 관한 것이므로 숫자 는 중요합니다. 더 정확하게, 그것은 숫자뿐만 아니라 SemVer의 맥락에서 숫자에 관한 것입니다 않는 문제뿐만 아니라 정확하게 지정 의미를 갖습니다.

— Jörg W Mittag

14

시맨틱 버전 관리가 올바르게 사용되었다고 가정하면, 시스템이 거의 4 개월마다 주요 변경을 수행하기 때문에 시스템이 제대로 설계되지 않았 음을 나타 냅니까?

반드시 그런 것은 아닙니다.

주석에서 이것이 내부 API라고 언급했습니다. 모든 사람의 코드를 깨뜨리기 때문에 API를 깨는 것은 좋지 않습니다. 그러나 내부 API의 경우 "모두"는 "귀하"이므로 이러한 API 변경을 사용자와 완벽하게 조정할 수 있으므로 일반적으로 API 변경과 관련된 고통은 훨씬 덜 심합니다.

또한 평균은 엄청나게 오해의 소지가있을 수 있습니다. 초기 개발 초기 며칠 동안 API 변경이 11 번 발생했으며 그 이후로 4 년 동안 안정적 이었습니까? SemVer를 사용 하면 주 번호가 0 인 경우 주 번호를 늘리지 않고도 주요 변경을 수행 할 수 있지만 강제 하지는 않습니다 . 아마도 프로토 타입 / 탐색 단계에서도 0 일부터 SemVer를 사용하기 시작했을까요?

— 요 르그 W 미타 그
소스

5

이 답변은 질문을 직접 해결하는 것으로 보입니다. OP의 의미 버전 관리에 대한 가정이 아닌 경우 다른 답변 중 일부가 유효합니다.

— joshp

또한 중요한 변경 사항이 항상 중요한 것은 아닙니다. 때때로 그들은 매우 작습니다 (아직 중요합니다). 따라서 사용자에게는 약간의 변경 만 필요합니다. 또한 API 사용 방법에 따라 많은 부분이 변경 될 수 있습니다. 예를 들어 주요 변경 사항이 모든 사용자에게 영향을 미치지는 않습니다. 또한 버그 수정으로 주요 변경 사항이 발생할 수 있지만 나중에 수정하는 것이 좋습니다. 그리고 API가 내부에 있다면 이러한 작은 변화를 처리하는 것이 훨씬 쉽습니다.

— Kat

1

짧은 답변

아니

긴 대답

"때로는 숫자가 숫자 일뿐"

현재 미친 세상에서 "의미론적인 버전 관리", "합리성", "논리적"은 잊어 버리십시오.

Chrome에서 왜 버전 번호가 그렇게 빨리 증가합니까?

"버전"숫자는 다른 개발자가 사용하는 방식을 대중에게 알리기 위해 메이저 릴리스가 아닌 지점 포인트의 마일스톤으로 사용됩니다. 그리고 종종 이벤트가 아닌 준비된 기능 또는 준비되지 않은 기능을 갖춘 지속적인 개발 흐름으로, 많은 새로운 기능을 결합하여 큰 이벤트를 만듭니다.

— 게으른 오소리
소스

7

OP는 시맨틱 버전 관리를 사용하고 있다고 밝혔다. 그렇다면 왜 무시합니까?

— Jörg W Mittag

-3

시맨틱 버전 관리를 사용할 때 여전히 "주요"로 간주되는 변경과 "부"로 변경되는 결정을 내립니다. 버전 번호가 충돌하거나 충돌하지 않는 여러 가지 이유가 있습니다.

이전 버전과의 호환성 약속이있는 시스템 은 다소 난해한 코너 케이스에서 이전 버전과의 호환성 중단이 발생하기 때문에 대부분의 업데이트로 주 버전 번호가 올라갈 수 있습니다. 동일한 시스템은 거의 종속적으로 1.xy를 고수 할 수 있습니다. 이전 버전과의 호환성을 위해 많은 노력을 기울이고 종속 시스템을 절대로 중단시키지 않기 때문입니다. 버전 번호 매기기에 대한 두 가지 접근 방식은 모두 "보수적"으로 간주 될 수 있지만 두 가지 모두 근본적인 문제의 징후 일 수 있습니다.

다른 경우에는 실제로 주요 버전 번호를 변경하는 것이 적합한 릴리스 일정 (고객에게 분기별로 업데이트 CD를 보내야 함)이 있으므로 "버전 3.4 / 10 월 16 일"대신 "버전 11.0"이라고 표시됩니다. 요즘에는 점점 더 많은 소프트웨어가 짧은 간격으로 릴리스되므로 릴리스 일정이 특정 버전 관리 체계를 고수 할 이유가 줄어 듭니다. 내부 IT가 분기 별 단 하루에 한 번 (일반적으로 일요일) 다운 타임을 허용하는 큰 창고 시스템에서 이것을 보았습니다. 이 날은 배포 일이며 매번 새로운 주 버전으로 표시됩니다.

일부 프로그램은 사용자가 동시에 두 가지를 모두 업데이트해야하기 때문에 외부 종속성 이 가장 중요합니다. Word 2010 및 Word 2013에서만 작동하는 Word-addon이있는 경우 주요 버전 번호를 MS-Word의 버전과 동기화 할 수 있습니다. 여기에서는 주요 사용자 수가 가장 중요합니다. 일부 사용자는 최신 버전의 Word (또는 SAP, Dynamics, 기타).

때로는 다른 외부 요인이 버전 번호를 지시하기도합니다. 회계 소프트웨어가있는 경우 세금 법에 해당하는 연간 업데이트가있을 수 있습니다 (1 월 1 일부터 시행되는 경향이 있음). 이러한 시스템은 업데이트 일정이 아니라 고객에게 다른 중요성 때문에 매년 1 회 정확하게 주요 버전이 변경됩니다. 2016 년 세금을 납부하면 2016 년 세금 법으로 업데이트되는 프로그램이 더 좋습니다.

결국, 버전 번호는 종종 하나의 도메인에만 해당되는 많은 요소에 의존하므로 숫자만으로는 코드베이스의 상태에 대해 아무 것도 알려주지 않습니다 . 배포가 언제, 왜, 어떻게 발생하는지, 그리고 얼마나 원활하게 진행되는지 확인하는 것이 훨씬 더 좋은 방법입니다. 10.000 고객에게 주요 업데이트를 제공하고 몇 건의 전화 통화를 할 수 있다면 아마 괜찮을 것입니다. 사소한 패치를 10 명의 고객에게 배포하고 그로 인해 초과 근무를해야하는 경우 문제가있을 수 있습니다.

— 하짓
소스

3

"시맨틱 버전 관리를 사용할 때 여전히"주요 "로 간주되는 변경과"부 "로 변경되는 결정을 내립니다." – 아니요, 없습니다. 그것은 사양에 정확하게 정의되어 있습니다. "버전 번호가 충돌하거나 충돌하지 않는 여러 가지 이유가 있습니다." – 아니요, 없습니다. 대수를 늘려야하는 이유는 정확히 하나 (이 질문에 관한 것)이며, 스펙에 정확하게 정의되어 있습니다.

— Jörg W Mittag

1

@ JörgWMittag 잘못 읽었거나 사양에 따라 버전 번호를 충돌 해야하는 시점이 명시되어 있지만 MAY 시점에 대해서는 아무 말도하지 않습니다.

— Hazzit

-4

버전 번호의 의미에 대한 의견은 실제로 major.minor.revision.buildnumber입니다.

전공이 빨리 올라가면 개발자가 이러한 새로운 아이디어를 모두 가지고 열심히 일할 수 있습니다.

그러나 비즈니스 세계에서는 주 버전 번호를 증가시키는 다른 이유가있을 수 있습니다. 처럼

판매가 중단되고 클라이언트 / 사용자가 업그레이드하기 전에 다음으로 큰 주요 릴리스를 기다리고 있습니다.
계약에 따르면 고객은 사소한 업데이트를받을 수 있습니다. 공급 업체는 비용을 청구 할 수 없으므로 약간의 개선이 주요 제품 업그레이드로 판매됩니다.
경쟁사 X는 게임에서 약간 더 오래 사용되었으므로 주요 버전 번호가 귀하보다 높습니다. 이것은 당신이 뒤처지고있는 것처럼 보이게합니다.

— 마틴 마트
소스

6

질문에 의미 체계 버전 이 지정되어 있고 OP가 질문에 의미 체계 버전을 언급하고 의미 체계 버전을 사용하고 있다는 의견에서 다시 확인했습니다. SemVer 사양은 주요 버전이 증가 할 때 매우 명확하게 나타납니다. "다른 이유"는 적용되지 않습니다.

— Jörg W Mittag