Backbone: SemVer 팔로우

감사합니다. 그러나 "의미론적" 버전 관리를 엄격하게 따르는 것은 Backbone에서 잘 작동하지 않을 것입니다. 프로젝트가 거의 모든 표면적이며 내부가 거의 없다는 점을 감안할 때 Backbone에 대한 거의 모든 변경(패치, 풀 요청)은 이전에 정의되지 않은 동작에 의존하는 사람들에게만 해당하더라도 약간의 방식으로 하위 호환성을 깨뜨립니다.

"의미론적" 버전 관리를 엄격히 따랐다면 지금 쯤이면 Backbone.js 43.0.0 이 될 것입니다. 이는 누구도 프로젝트의 실제 진행 상황을 평가하는 데 도움이 되지 않습니다.

그래서 저는 농담을 좋아합니다. "의미적인" 버전 관리가 아니라 _낭만적인 버전 관리_입니다.

버전 번호 MAJOR.MINOR.PATCH가 주어지면 다음을 증가시킵니다.

주요 새 릴리스를 만들거나 API를 크게 업데이트 및/또는 안정화할 때 MAJOR 버전입니다.
사소한 새 기능을 추가할 때의 MINOR 버전입니다.
PATCH 버전은 작은 변경을 할 때 대부분의 사람들이 알아차리지 못할 가능성이 있습니다.

이를 통해 사람들은 새 릴리스에 대해 듣자마자 그 범위를 대략적으로 알 수 있습니다. 이전 버전과의 호환성 - 이상적으로는 _모든_ 릴리스, 심지어 주요 릴리스도 이전 버전과 호환됩니다. 그리고 API가 변경되기 때문에 그렇게 할 수 없을 때는 업그레이드가 너무 어렵지 않은 방식으로 수행되어야 합니다.

그러나 API에 대한 변경을 피하고 "MAJOR" 릴리스가 준비되기를 기다리는 것은 진행에 큰 장애물이 될 것입니다. 그리고 MAJOR 버전 번호를 자주 증가시키는 대안은 엄청나게 도움이 되지 않습니다.

솔직히 말해서, 대부분의 데스크톱 응용 프로그램과 마찬가지로 BIG.SMALL 버전 번호를 사용하는 더 간단한 구성표를 선호하지만 패키지 관리자 및 기타 도구를 손상시키는 것에 대해 걱정할 것입니다.

Backbone 43.0.0에 있는 문제는 무엇입니까?

• Chrome 32.0.1700에서 전송됨

spadgos@ 질문에 +1. 버전 번호는 임의적입니다. 어떤 이유로 OS와 동일한 범위 내에서 유지하려는 애자일 웹 앱이 있습니다. 많은 앱이 10을 넘기는 것을 두려워하지만... 모델링하는 대부분의 프로젝트(Windows, Linux 등)는 릴리스 전에 1년/다년 개발 주기가 있으므로 1.x -> 2.x 큰일이다. 애자일 프로젝트는 매우 빠르게 움직이며 빠르게 증가하는 것도 의미가 있습니다.

저도 그 근거에 동의하지 않습니다.

Marionette는 현재 v1.2.3에 있으며 엄격한 의미론적 버전 관리를 따르는 것이 최선입니다. 지금까지 우리는 "모든 표면적"인 경우에도 문제가 없었습니다. 새로운 기능을 추가했습니다. 버그를 수정했습니다. 그러나 v1.0은 여전히 ​​v1.2.3과 호환됩니다. API 또는 예상되는 동작 중단 변경 사항인 경우 v2 릴리스에 대한 티켓을 연기했습니다.

풀 리퀘스트가 수락될 때마다 브레이킹 체인지가 포함된 주요 릴리스가 매주 발생할 필요는 없습니다. 이는 주요 버전 범프가 있는 대규모 릴리스에 대한 충분한 가치를 포함하는 주요 릴리스에 풀링될 수 있고 그래야 합니다.

그대로, v1.1 릴리스에서 호환성을 깨는 것은 MarionetteJS 팀과 같은 플러그인 및 애드온 개발자에게 많은 고통을 안겨줍니다. v1.0과 v1.1 모두에서 실행 가능하도록 코드의 패치로 동작을 다시 채워야 했습니다. 재미있는 상황이 아닙니다. 주요 변경 사항이 있는 Backbone과 같은 핵심 라이브러리의 파급 효과는 엄청납니다... 영향을 받는 것은 Backbone만이 아닙니다.

나는 이것이 "할 수 없다"라기보다 "하고 싶지 않다"의 경우처럼 보인다는 데 동의한다. https://github.com/jashkenas/backbone/pull/2461 과 같은 주요 변경 사항은 긴급한 의미가 없으며 43.0.1 문제를 원하지 않는 경우 주요 버전 업데이트를 기다릴 수 있습니다.

저에게 백본이 semver를 존중하지 않는 가장 큰 문제는 (무엇보다도) 백본을 가르치고 복음화하는 데 있습니다. 백본을 제외하고 스택에 있는 모든 것이 특정 방식으로 작동할 것이라고 학생 그룹이나 잠재 고객에게 말하는 것은 좋지 않습니다.

Backbone을 "복음화"할 때 항상 두 가지 큰 경고가 있었습니다. 바로 AMD가 아니며 SemVer를 존중하지 않으므로 버전 번호를 심각하게 받아들이지 마십시오. 그 중 하나는 고정되어 있습니다. 다른 하나를 수정합시다.

솔직히 말해서, 나는 대부분의 데스크탑 응용 프로그램과 마찬가지로 BIG.SMALL 버전 번호를 사용하는 더 간단한 체계를 선호하지만 패키지 관리자 및 기타 도구를 손상시키는 것에 대해 걱정할 것입니다.

@jashkenas 우리는 항상 세 번째 숫자를 .0으로 남겨둘 수 있습니다. :)

그것은 아마도 우리가 지금 하고 있는 것보다 조금 더 가까운 SemVer에 의미적으로 매핑될 것입니다. SemVer를 따르지 않는 것이 기술적으로 어떻게 잘못된 것인지에 대한 수동적-공격적 암호-정치적 저격을 억제할 수도 있습니다.

우리가 어떤 시스템을 따르든, 우리가 어떤 시스템을 따르고 있는지 명확하게 표현하는 것이 더 중요하다는 점에서 Bob의 요지가 옳다고 생각합니다.

ps @keithamus 의 문제가 수동적이며 공격적이라는 의미는

:+1: semver용. 나는 주로 진행 상황의 지표가 아니라 호환성의 지표로서 주어진 소프트웨어 버전에 관심이 있습니다.

일반적으로 1.0 이후(대부분 안정적이고 작동할 것으로 예상되는 경우) 버전 번호는 진행률을 나타내는 지표로 거의 의미가 없습니다. 버전 10의 소프트웨어 X는 버전 2의 소프트웨어 Y보다 훨씬 덜 성숙하고 기능이 적을 수 있습니다. 소프트웨어의 진행 상황을 알고 싶다면 변경 로그나 로드맵을 살펴봐야 합니다.

백본(또는 무엇이든)이 2.4.3에 있다는 사실을 아는 것은 기능 측면에서 아무 의미가 없습니다. 그러나 그것은 _반드시_ 내가 2.0.4에서 아무런 문제 없이 업그레이드할 수 있다는 것을 의미합니다.

"의미론적" 버전 관리를 엄격히 따랐다면 지금쯤이면 Backbone.js 43.0.0이 될 것입니다. 이는 누구도 프로젝트의 실제 진행 상황을 평가하는 데 도움이 되지 않습니다.

아주 사소한/아마도 존재하지 않는 문제. semver를 팔로우하지 않습니까? 큰 문제.

:+1:, semver는 그런 큰 프로젝트에 꼭 필요한 도구입니다.

@knowtheory와 함께합니다. 43.0.0 좀 이상해 보이지만 1.43.0 괜찮고 npm install 이후에 아무도 놀라지 않을 것입니다.

누가 높은 버전 번호에 신경을 쓰나요?
표준이니 사용할 수 있으면 사용해야 합니다.
이 토론이 왜 그렇게 오래 가는지 도무지 이해가 되지 않습니다.

:+1: #2996 및 #2997의 일부 문제를 방지할 수 있었고 다른 몇 가지 다른 Backbone 릴리스와 함께 발생한 문제를 방지할 수 있었습니다.

@braddunbar (그리고 "반대"의 나머지 이유)는 실제 의미보다 버전 번호의 미학을 더 중요하게 생각하는 것처럼 들립니다.

감사합니다. 그러나 "의미론적" 버전 관리를 엄격하게 따르는 것은 Backbone에서 잘 작동하지 않을 것입니다.

나는 그것이 사용자를 위해 잘 작동하는 Backbone에 관한 것이라고 생각합니다(종속성 관리 포함). 다음 semver가 보장하는 것은…

더 자주 릴리스하면 쇼스토퍼 버그를 더 빨리 잡는 데 도움이 됩니다. 사람들에게 필요한 버그 수정을 얻기 위해 Backbone의 에지 버전을 지속적으로 실행하도록 요구하는 것은 너무 과하다고 생각합니다.

+1 @derickbailey

예를 들어 1.1.0 이후 패치 릴리스의 아이디어는 이러한 수정이 전혀 필요하지 않아야 한다는 것입니다.

https://github.com/marionettejs/backbone.marionette/commit/5a498d250d23a68c9c84a1362782edcf8774a1c8

https://github.com/marionettejs/backbone.marionette/commit/baed36bad8357e4379d4d2bc0460fd1375d2c85b

https://github.com/marionettejs/backbone.marionette/commit/e13e912bdda8e056c0e7b5e15d127eff158a48cb#diff -3c2771f47bdfe073ea95bfa54a37a972R167

npm 또는 bower 패키지의 경우 이것은 논쟁의 대상이 아닙니다.

npm 또는 bower를 사용하여 패키지를 게시할 때 semver는 귀하가 체결하는 API 계약의 일부입니다. 그 계약을 깨면 당신에게 의존하는 다른 모듈이 깨집니다. 당신은 당신의 모듈에 의존하는 생산 코드를 깨뜨립니다.

문제는 "semver를 사용해야 합니까?"가 아닙니다. 문제는 "우리가 생태계에서 좋은 시민이 되기를 원하는가?"입니다.

대답이 아니오인 경우 API 계약을 따르는 다른 패키지처럼 패키지를 설치하는 것이 안전하지 않기 때문에 크고 명확하게 알려야 합니다.

npm 또는 bower를 사용하여 패키지를 게시할 때 semver는 귀하가 체결하는 API 계약의 일부입니다.

아니, 그렇지 않다. npm install --save [email protected] 는 번거로운 요구 사항이 아닙니다.

@akre54 semver에 대한 당신의 관점에 관심이 있습니다. @jashkenas가 그것에 대한 생각을 알고 있지만 당신의 생각은 무엇입니까?

@akre54 네 그렇습니다. npm은 저장소의 모든 패키지가 semver 를 따른다고 가정합니다. 이것이 어떤 패키지가 어떤 패키지와 호환되는지 결정하는 방법입니다.

package.json 문서에서:

"버전은 종속성으로 npm과 함께 번들로 제공되는 node-semver에서 구문 분석할 수 있어야 합니다. (npm install semver를 사용하여 직접 사용하십시오.)"

버전 번호가 semver로 해석될 때 _lie_이면 올바른 구문 분석이 아닙니다. 따라서 package.json 계약을 위반하고 사람들이 npm 생태계에서 패키지 버전을 사용하는 방식과의 호환성을 위반하고 있습니다.

개인 취향의 문제만은 아닙니다. 패키지 상호 운용성의 문제입니다.

semver를 사용하지 않는 경우 패키지가 멋지게 재생되도록 강제할 수 있습니까? _물론입니다_, 하지만 readme의 맨 위에 큰 소리로 대담하게 말하지 않으면 -- 이것이 필요하다는 것을 아는 사용자는 거의 없을 것이며, 브레이킹 체인지를 도입할 때 코드가 매우 쉽게 손상될 수 있습니다.

패키지 리포지토리에 패키지를 게시하면 버전 관리가 상호 운용성 계약의 일부가 됩니다. 사용자의 위험을 무릅쓰고 해당 계약을 무시합니다.

npm install --save [email protected] 는 번거로운 요구 사항이 아닙니다.

완전한 응용 프로그램에 들어가는 수천 개의 패키지 중 어느 것이 번거로운 요구 사항인지 _is_ 알고 있습니다. 소수의 모듈이 규칙을 따르지 않기 때문에 사용자가 모든 패키지의 버전을 단단히 잠그도록 강요합니다. 버그 수정, 보안 패치 등을 따라가는 문제를 복잡하게 만들기 _is_ 번거로운 요구 사항입니다.

semver를 팔로우해야 하는 아주 좋은 이유가 있습니다. "내 패키지 번호가 정말 커질 수 있습니다"는 semver를 사용하지 _않는_ 끔찍한 이유입니다. 애플리케이션의 진행 상황을 추적하는 것은 패키지 버전에 대한 두 번째 이유입니다. 버전의 가장 중요한 기능은 "이 버전이 내 애플리케이션에서 작동합니까?"를 아는 것입니다.

BTW, 패키지 번호가 정말 커지면 코드 냄새 일 수 있습니다. _브레이킹 체인지_를 할 때만 메이저 버전을 변경하면 됩니다. 정의에 따른 주요 변경은 _개방/폐쇄 원칙을 위반하는 것입니다. 확장을 위해 열리고 주요 변경을 위해 닫힙니다. 모든 좋은 API는 합리적으로 가능한 한 가깝게 개방/폐쇄 원칙을 따르므로 사용자가 API를 따라갈 수 있고 변경 사항으로 인해 기존 코드가 손상되지 않습니다.

여기서 배운 교훈은 "package.json을 통해 백본을 가져올 때 ~ 또는 ^ 사용하지 마십시오"라는 것입니다.

@akre54 semver 에 대한 당신의 관점이 궁금합니다

일반적으로 나는 여기의 주장에 동의하지만 주 버전을 범하는 것이 _모든_ 주요 변경 사항에 대한 최선의 조치인지 궁금합니다. Underscore는 많은 타사 라이브러리에서 사용되며 거대한 버전을 따라잡기 위해 모두를 요구하는 것은 힘들고 위험합니다. (오늘 출시된 패키지는 버전 2까지 Underscore에 의존해야 합니까? 1.7? 1.6.x? 메인 프로젝트에서 별도의 Underscore를 요구하는 대신 종속성을 고정해야 합니까?)

여기에서 배운 교훈은 "package.json을 통해 백본을 가져올 때 ~ 또는 ^를 사용하지 마십시오"라고 생각합니다.

네.

여기에서 배운 교훈은 "package.json을 통해 백본을 가져올 때 ~ 또는 ^를 사용하지 마십시오"라고 생각합니다.

나는 한 설명 보다 이 테이크 아웃 수업 안하는 이유.

여기에서 배운 교훈은 "package.json을 통해 백본을 가져올 때 ~ 또는 ^를 사용하지 마십시오"라고 생각합니다.

결과적으로 코드가 손상되지 않도록 보호하는 것입니다.

수업은 "semver를 따르는 것은 모두에게 좋지만 그렇게 하지 않는 것은 좋지 않습니다."와 비슷할 것입니다.

나는 "낭만적인" 버전 관리의 가치를 이해할 수 있습니다. 잘 공존하지 않는 것이 아쉽습니다.

항상 semver를 매우 엄격하게 따르지 않는 프로젝트와 시도하지만 미달하는 프로젝트가 있으므로 시스템이 항상 약간 누출된다는 점에 유의해야 합니다.

적어도 Backbone은 일반적으로 물건을 부수지 않는 데 매우 좋습니다.

@dgbeck 상황은 버전별로 항상 중단됩니다. 이전 의견을 참조하십시오.

따라서 실제로 언급되지 않은 semver를 따르는 것의 가치는 사소한 기능과 버그 수정을 푸시하고 업스트림에 의존하는 사람들이 이러한 변경 사항을 무료로 얻을 수 있도록 허용한다는 사실입니다.

나에게 이것은 훌륭한 부가 가치이지만 분명히 이것은 유지 보수의 복잡성을 대가로 치러야 합니다.