Underscore: 밑줄은 SemVer를 따르지 않습니다.

인용 https://github.com/jashkenas/backbone/issues/2888#issuecomment -29076249:

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

동의하지 않더라도 나머지 의견도 읽을 가치가 있습니다.

https://github.com/jashkenas/coffeescript/issues/3352#issuecomment -34217211 너무

@akre54 Lo-Dash(Underscore 대안) 및 ExosJS(Backbone 대안)와 같은 다른 프로젝트가 semver를 따를 수 있다는 사실에 대해 어떻게 생각하는지 궁금합니다.

그 드롭인 교체가 _semver를 따를 수 있기 때문에_ Underscore/Backbone 코어가 밀어붙이는 변명에 그런 종류의 렌치를 던지지 않습니까?

몇 가지.

Lo-Dash는 대부분 Underscore가 포장한 좁은 길을 고수하므로 Underscore 릴리스까지 보류하여 기능 패리티를 위한 버전 범프를 푸시하는 이점이 있습니다. 밑줄과의 차이점은 향상 범주에서 더 많고 중요한 주요 변경 사항이 적은 경향이 있습니다.

Lo-Dash는 코드 혼란을 희생시키면서 bc에 대해 훨씬 더 많은 보호 코드를 추가하는 반면 Underscore는 간결함을 위해 노력합니다. 라이브러리가 더 클 때 몇 줄의 추가 코드로 시작하는 것이 더 쉽습니다. 논리의 많은 부분이 내부에 있으므로 대시하세요.

또한 한 기여자 (귀하)가 불균형적으로 작성하는 반면 Underscore의 변경 사항은 훨씬 더 다양한 기여자 집합에서 오는 경향이 있습니다. 출시 일정.

일화적으로, 저는 Underscore가 Lo-Dash보다 더 많은 초보자 프로젝트에서 사용된다는 릴리스 일정의 단점이 있다는 느낌을 받았습니다. 고급 개발자는 브레이킹 체인지에서 오는 여파에 더 편안하게 대처할 수 있으며 그들의 추론을 조금 더 이해할 수 있습니다.

마지막으로, Exoskeleton의 공동 저자이자 수석 기고자로서 저는 우리도 semver를 팔로우하지 않았다는 사실을 가장 먼저 알려드립니다. 우리는 또한 위에서 설명한 Lo-Dash의 장점을 가지고 있습니다.

Lo-Dash는 대부분 Underscore가 포장한 좁은 길을 고수하므로 Underscore 릴리스까지 보류하여 기능 패리티를 위한 버전 범프를 푸시하는 이점이 있습니다. 밑줄과의 차이점은 향상 범주에서 더 많고 중요한 주요 변경 사항이 적은 경향이 있습니다.

Underscore의 버전 전략과 어떤 관련이 있습니까? Lo-Dash는 semver 이후 버전을 충돌시키므로 v2.x에서 v3.x로 진행됩니다.

Lo-Dash는 코드 혼란을 희생시키면서 bc에 대해 훨씬 더 많은 보호 코드를 추가하는 반면 Underscore는 간결함을 위해 노력합니다.

가드 코드나 간결함이 버전 전략과 어떤 관련이 있습니까?

라이브러리가 더 클 때 몇 줄의 추가 코드로 시작하는 것이 더 쉽습니다(Lo-Dash는 8.7k 라인에서 시작하고 Underscore에서는 1.4k 라인에서 클럭).

Lo-Dash에는 인라인 문서가 있으며 LOC는 버전 관리와 관련이 없습니다.

로직의 많은 부분이 내부적이기 때문에 Lo-Dash에서 수행할 수 있는 내부 mucking이 훨씬 더 많습니다.

Underscore도 마찬가지 아닐까요?

또한 한 기여자(귀하)가 불균형적으로 작성하는 반면 Underscore의 변경 사항은 훨씬 더 다양한 기여자 집합에서 오는 경향이 있습니다. 출시 일정.

이것이 Underscore에 유지 관리자가 수락/거부 또는 향후 릴리스까지 미루는 이유입니다.
다시 말하지만 버전 관리와 관련이 없습니다.

일화적으로 저는 Underscore가 Lo-Dash보다 훨씬 더 많은 초보자 프로젝트에서 사용된다는 단점이 있다는 느낌을 받았습니다.

나는 동의하지 않습니다. Lo-Dash에는 수천 명의 부양 가족이 있으며 모두 전문가가 될 수는 없습니다.

고급 개발자는 브레이킹 체인지에서 오는 여파에 더 편안하게 대처할 수 있으며 그들의 추론을 조금 더 이해할 수 있습니다.

Lo-Dash는 semver를 따르기 때문에 개발자는 주요 버전 업데이트로 이동할 때까지 낙진을 처리할 필요가 없습니다. Underscore와 달리 Lo-Dash는 패키지 버전 범위에 ~ 를 사용했기 때문에 발 아래에서 변경되지 않습니다.

마지막으로, Exoskeleton의 공동 저자이자 수석 기고자로서 저는 우리도 semver를 팔로우하지 않았다는 사실을 가장 먼저 알려드립니다.

그런 다음 마케팅에서 이를 제거해야 합니다.

Underscore가 semver를 못 따라갈 이유가 없다고 생각합니다.
이를 따르지 않는 것은 사용자에게 실례입니다.

npm이나 bower에 포함되기를 원한다면 토론의 대상이 아닙니다. semver를 사용해야 합니다. 당신은 semver를 따르겠다는 암묵적인 약속을 하고 있고, 그렇게 하지 않으면 경고 없이 사람들의 코드를 깨뜨리고 거의 모든 사람이 눈살을 찌푸리게 됩니다.

우리는 생산 코드를 깨는 선택에 대해 이야기하고 있습니다. 남의 시간과 돈을 가지고 조잡한 게임을 하는 것은 쿨하지 못하다.

즉, 버전 번호가 더 빨리 커집니다. 그래서 무엇? 그것은 숫자입니다. 그것은 누군가의 생산 장바구니를 깨는 것보다 훨씬 낫습니다.

셈버의 경우 +1

개인적으로, 나는 버그 리포트에서 _personal_을 얻는 것이 "멋지다"고 생각하지 않습니다. 의미론적 버전 관리를 따르거나 따르지 않습니다. 여기에 이유가 있습니다. 쾅, 쾅, 쾅 -- 그렇게 된다면 더 나은 라이브러리가 되는 이유입니다. 여기에 이유가 있습니다. 쾅, 쾅--유지 관리자가 semver와 일치하는 방식으로 버전 번호를 증가시키는 것이 가능한 이유입니다.

그 후는 유지 보수의 몫입니다. 그들의 입장에 동의하지 않는다면 사용할 대체 라이브러리가 있습니다. 프로젝트를 포크할 수 있습니다(다른 사람들이 한 것처럼). 원하는 대로 개인 블로그 게시물을 작성할 수 있습니다.

그러나 시민적 의견 불일치를 시도합시다.

@raganwald를 이해하지 못합니다. 누가 사적인가?

나는 누구를 공격하지 않습니다. semver는 npm이나 bower에 패키지를 게시할 때 체결하는 API 계약의 일부라는 점을 지적하고 있습니다.

그 계약을 어기면 다른 사람의 코드도 깨집니다. 멋지지 않아.

npm은 우리 모듈이 서로 잘 작동하도록 유지하는 몇 가지 규칙에 모두 동의하기 때문에 정말 잘 작동합니다. 이러한 규칙을 어기면 당신과 함께 작동하는 다른 모듈도 깨집니다. 코드에 의존하는 프로덕션 앱을 중단합니다.

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

요점은 Underscore와 같은 프로젝트에서 _모든_ 변경 사항이 누군가에게 영향을 미친다는 것입니다. _.extend 에서 null 가드를 제거하면(임의의 예를 사용하여) 누군가에게 버그를 일으키고 다른 누군가에게는 버그를 생성하기 때문에 패치인가요? 마이너 버전인가요? 주요한?

Underscore 및 Backbone의 경우 종속성을 고정하는 것이 부당하다고 생각하지 않습니다. 다음 semver는 패키지 프로그램에 게시하기 위한 요구 사항이 아닙니다.

요점은 Underscore와 같은 프로젝트에서 모든 변경 사항이 누군가에게 영향을 미친다는 것입니다.

당신은 당신의 입장을 정당화하기 위해 극단으로 뛰어오르고 있습니다. 현실은 균형입니다. 인기 있는 API, 엣지 케이스 및 문서화된 동작이 있습니다. 단순히 버그를 수정하고 기능을 추가하여 메이저 버전과 충돌하지 않고 시간을 연장할 수 있습니다.

그것이 의미하는 바는 유지 보수가 생각하고 계획해야 한다는 것입니다. 즉, 이전 버전과의 호환성을 깨뜨리지 않고는 해결할 수 없는 기능이나 변경 사항에 대한 로드맵을 만들어야 할 수도 있습니다.

Underscore는 패치 릴리스를 확장하고 주요 변경 사항을 도입했습니다. 이것은 관리자가 완전히 제어할 수 있는 것입니다.

Underscore 및 Backbone의 경우 종속성을 고정하는 것이 부당하다고 생각하지 않습니다.

문서에 확실히 메시지/경고가 있어야 합니다.

@akre54 _ 문서화되지 않은_ 기능 또는 _문서화되지 않은 버그_를 변경하면 이에 의존하는 코드가 중단될 수 있지만 사용자는 문서화되지 않은 기능과 버그에 의존하여 위험을 감수해야 합니다.

semver를 무시하면 API의 _모든 사용자_가 위험에 처하게 됩니다. 사람들은 항상 semver를 따르는 대규모 오픈 소스 프로젝트에서 버그를 수정하지만 _npm 생태계에서 큰 버전 번호를 보는 것은 정말 드뭅니다_.

왜 그런 겁니까?

_모든 좋은 API는 개방/폐쇄 원칙_(확장은 개방, 변경은 폐쇄)을 최대한 가깝게 따르므로 사용자가 API를 따라갈 수 있고 변경으로 인해 기존 코드가 손상되지 않습니다.

일화에 추가하자면, 내 코드는 과거에 Underscore 범프로 인해 손상되었습니다. --save --save-exact 가 잘리지 않기 때문에 이를 방지하기 위해 node_modules 커밋에 의존했습니다. 두 번째 수준 종속성이 Underscore에 의존하고 ^x.y.z 버전을 사용하는 경우 앱은 여전히 ​​손상됩니다.

진행 상황을 나타내는 버전 번호는 신경 쓰지 않습니다. 버전 2.1.3 또는 143.3.2를 사용해도 별 차이가 없습니다. 라이브러리 진행 상황과 완성도는 버전 번호로 측정되지 않습니다. 누군가 underscore@^x.y.z 에 의존하는 종속성을 업데이트했기 때문에 일요일 오후에 전화를 걸고 싶지 않습니다.

:엄지손가락: 네. @braddunbar 는 내가 아직 이해하지 못한 점을 지적합니다. semver를 무시하면 패키지가 위험하고 치명적인 패키지가 됩니다. 그 주요 변경 사항이 _어디서든_ 남아 있을 수 있기 때문입니다.

사용자가 깨진 패키지에 의존하는 타사 코드의 중단을 추적하도록 강제하는 것은 _확실히 힘든 요구 사항입니다.

IMO, 실제 도서관 진행 상황 및 성숙도는 신뢰성으로 측정되며 semver는 그 목표를 달성하기 위해 먼 길을 가고 있습니다.

문서에 확실히 메시지가 있어야 합니다.

분명히. 그것이 우리가 결정한다면 하나를 추가하게 되어 기쁩니다.

저는 더 나은 릴리스 시스템에 반대하지 않습니다(주님은 작은 버그 수정이 배포되기까지 몇 달을 기다리는 것이 고통스럽다는 것을 알고 있습니다). 그러나 "semver를 따르십시오"가 하나의 정답인지 확신할 수 없습니다.

지금은 하나의 정답이어도 상관없다고 생각합니다. 커뮤니티에서 수락한 답변입니다.

"semver를 따르십시오"가 더 나은 릴리스 시스템에 대한 정답이라고 아무도 말하지 않았습니다. 우리가 말한 것은 npm API 계약이며 해당 계약을 위반하면 손상을 입힐 수 있다는 것입니다.

@jdalton 및 @dilvie 릴리스를 처리하는 방법을 제안하시겠습니까? 기능을 수락하는 것은 어떻습니까? "Use semver"는 실제로 우리에게 아무 것도 알려주지 않습니다.

현재 코드에 대한 버그 수정을 기다릴 수 있도록 _.matches 와 같은 기능을 몇 개월 뒤로 미루어야 합니까, 아니면 지금 출시하여 사람들이 구현 문제를 해결하도록 해야 합니까?

나는 semver가 여기에 완전히 적용되지 않는다고 생각합니다.

뻔뻔한 자기 홍보: next-update https://github.com/bahmutov/next-update 를 사용하여 프로젝트 중단 없이 종속성을 업데이트할 수 있는지 먼저 테스트하십시오. *.*.x 가 변경되었음에도 불구하고 다른 모듈에서 계속해서 주요 변경 사항이 발견되었으므로 이제 자체 선언된 버전을 신뢰하지 않습니다.

이 프로젝트가 눈송이라고 생각하십니까? Lo-Dash는 기본적으로 Underscore++이며, @jdalton은 semver를 따라가도 문제 없습니다.

새로운 기능 수락:

기존 API 계약을 위반합니까?

네? - 범프 메이저 버전 번호.
아니요? - 범프 마이너 버전 번호.

버그 수정/마이너 패치 수락:

기존 API 계약을 위반합니까?

네? - 범프 메이저 버전 번호.
아니요? - 범프 패치 버전 번호.

공식 릴리스 일정을 선택하는 방법은 전적으로 귀하에게 달려 있습니다. 다른 사람의 코드를 손상시키지 않도록 버전 관리가 semver와 호환되는지 확인하십시오.

https://github.com/jashkenas/underscore/compare/1.3.3...1.4.0 과 같이 @dilvie 에 동의했습니다. 희소 배열에 대한 지원을 중단했기 때문에 아마도 큰 문제가 되었을 것입니다. 다음 버전은 lookupIterator 를 통해 많은 양의 새로운 설탕을 추가하고 기본 반복자를 삭제하므로 큰 변화가 있을 것입니다.

기능의 문서가 명백히 주요 변경 사항을 변경해야 하는 경우

올해 JSconf에서 이에 대한 간단한 토론을 했습니다. 여기에서 자세히 설명할 시간이 없지만 다음과 같습니다.

인간이 대면하는 "버전 관리"와 컴퓨터 대면(또는 실제로는 빌드 시스템 대면) "API 호환성"을 혼동하지 마십시오. 그냥 멈춰.

버전: "내가 좋아하는 이 기능에 새로운 기능이 있거나 시간이 있을 때 관심을 가져야 할 다른 기능이 있습니다." 새로운 아이폰이 있습니다. 새로운 OS X가 있습니다. 새로운 Ember가 있습니다. 알고리즘 언어 체계에 대한 새로운 수정 보고서가 있습니다.

API 호환성: “이것은 수정하도록 업데이트되었습니다.문제, 그리고 이것은 길을 깰 수 있습니다.그런 걸 연습해.” iPhone의 전원 플러그가 교체되었습니다. OS X에서 더 이상 사용되지 않는 리소스 포크. Ember는 작업 이름 스타일을 더 이상 사용하지 않습니다. 이제 스키마는 대소문자를 구분합니다.

후자는 전자를 _중에_ 또는 _옆에서_ 발생합니다. 그러나 전자가 반드시 후자에 의존하거나 관련이 있는 것은 아닙니다. 그것들은 추적되어야 하고 (정말로 버전 관리 시스템을 _지정_하려는 경우) 별도로 지정해야 합니다. (JS 커뮤니티에서 인기 있는 '시맨틱 버전 관리'의 개념은 _특히_ 둔하고 끔찍하지만, 다시 말하지만, 다른 사람의 Issue comment-thread에 대해 자세히 설명하고 싶지는 않습니다.)

tl;dr: 그들은 자신의 길을 선택하여 생태계를 망치고 있지 않습니다. (_특히_ 그 경로에 심각한 결함이 있는 경우.) 더 많은 프로젝트가 있었으면 합니다. 모양이 너무 구부려지면 다른 것을 사용하십시오.

@elliottcable - 사람 대면 대 컴퓨터 대면에 대해 동의했습니다 ... 사람 대면이 컴퓨터 대면처럼 보이지 않는 한 융합이 덜 문제가 됩니다.

다음 사람을 향한 릴리스를 nnn 대신 "눈송이"라고 부를 수도 있습니다.

그러나 마지막 부분에 완전히 동의하지 않습니다. API 계약을 따르는 척하다가 이를 어기면 문제가 발생합니다. 그것은 다른 사람들에게 실제 시간과 실제 돈을 요합니다. 밑줄만큼 인기 있는 프로젝트를 사용하면 잠재적으로 많은 실제 피해가 발생할 수 있습니다.

기존 API 계약을 위반합니까?

이 스레드의 맨 처음 인수를 다시 살펴보세요. "Underscore의 모든 것은 기본적으로 표면적입니다." 즉, 문서화되고 문서화되지 않은 모든 것이 API 계약의 일부입니다. 하나의 변화는 모두를 위한 변화입니다.

"Underscore++"인 Lo-Dash는 주요 기능을 작업할 때 Underscore 뒤에 안전하게 따를 수 있기 때문에 기능의 거의 많은 변경 사항을 처리하지 않습니다. Lo-Dash의 개선 사항은 기본적으로 기능을 재고하지 않고 주로 내부에 있거나 몇 가지 방법을 추가하는 것입니다.

@akre54

릴리스를 처리하는 방법을 제안하시겠습니까? 기능을 수락하는 것은 어떻습니까? "Use semver"는 실제로 우리에게 아무 것도 알려주지 않습니다.

새 API 또는 기존 API에 대한 일부 개선 사항을 수락할 수 있습니다. 새로운 API 또는 개선 사항(호환성을 손상시키지 않는)을 추가하는 경우 마이너 버전 업데이트입니다.

현재 코드에 대한 버그 수정을 기다릴 수 있도록 _.matches 와 같은 기능을 몇 개월 뒤로 미루어야 합니까, 아니면 지금 출시하여 사람들이 구현 문제를 해결하도록 해야 합니까?

_.matches 는 꽤 직관적이라고 생각합니다. 항상 버그 수정이 있을 것입니다.

나는 semver가 여기에 완전히 적용되지 않는다고 생각합니다.

물론 그렇습니다. 당신은 semver와 별개인 릴리스 주기 문제로 기어가기 시작했지만, 저는 당신을 따라갈 것입니다.

@dilvie : 나머지 인수에서 벗어나지만 이것을 던지면 '버전 이름' 규칙을 따르라는 제안이 정말 정말 좋습니다. (=

사람을 대면하는 부분의 경우 저는 less 스타일 버전 관리의 열렬한 팬입니다.

> less --version
less 418
Copyright (C) 1984-2007 Mark Nudelman

less comes with NO WARRANTY, to the extent permitted by law.
For information about the terms of redistribution,
see the file named README in the less distribution.
Homepage: http://www.greenwoodsoftware.com/less

... 우리가 API 호환성이 아니라 "흥미로움" 버전에 대해 이야기하고 있다는 것을 더 명확하게 하기 위해 예쁜 이름과 함께 사용하면 성공적인 콤보를 얻게 됩니다.

밑줄 42의 경우 +1: "바보 같은 셸티"

(빌드 시스템이 직면하는 부분에 관해서는 자동화된 생성 API 호환성에 대해 논란의 여지가 있는 견해가 있습니다. 오류가 있는 유지 관리자의 손에서 이 문제를 해결하고 정적 분석 또는 동적 크롤링으로 공격합시다.)

@akre54

"Underscore++"인 Lo-Dash는 주요 기능을 작업할 때 Underscore 뒤에 안전하게 따를 수 있기 때문에 기능의 거의 많은 변경 사항을 처리하지 않습니다.

그게 무슨 뜻이야? Lo-Dash는 _추가 변경 사항_을 처리하고 Underscore와 별도로 자체 버전 관리를 따릅니다. Lo-Dash는 너무 많이 변경되어 드롭인 교체 지원을 계속하기 위해 Underscore 호환 빌드를 제공해야 했습니다. 우리는 다른 기능 , 방법 및 다른 API 호환성 문제를 가지고 있습니다.

Lo-Dash의 개선 사항은 기본적으로 기능을 재고하지 않고 주로 내부에 있거나 몇 가지 방법을 추가하는 것입니다.

그것도 그렇지 않습니다. Lo-Dash는 더 빠른 속도로 움직이며 더 자주 백 컴퍼트에 맞서게 됩니다. 이것이 우리가 ~v3.x에서 ~v2.x를 진행하는 이유입니다. Lo-Dash는 밑줄과 같습니다. Lo-Dash가 semver를 따를 수 있다면 Underscore도 따를 수 있습니다. 나는 지금 ~ 2 년 동안 그것을했습니다. 당신의 주장은 현실 앞에서 그냥 무너집니다.

전에도 이 길을 걸어본 적이 있으므로 여러분도 거기에 가는 것을 도울 수 있습니다.
우선, 다음 Underscore 릴리스는 훌륭한 2.0이 될 것입니다.

모두가 "브레이킹 체인지"를 어떻게 정의해야 한다고 생각하는지 궁금합니다. 밑줄에 대한 _모든_ 새로운 기능 변경은 다른 사람에게 있어 획기적인 변경입니다.

_.each 에 대한 모든 최근 변경 사항을 예로 들어 보겠습니다. 원래 목록을 반환하기 위해 _.each 의 반환 값을 변경할 때 충돌해야 합니까? 버그픽스인가요? 새로운 기능? 이전 버전과 호환되지 않는 변경 사항? 이전에 undefined 를 반환했으므로 누군가의 코드를 깨뜨렸을 가능성은 없습니다.

내부 each 도우미가 외부적으로 재할당 되도록 허용할 때 충돌해야 합니까? 누군가의 코드가 손상되었을 수 있습니까? 공개 API는 변경되지 않았습니다.

희소 배열을 피하기 위해 _.each 를 변경하고 기본 forEach 대신 for 루프를 사용하는 것은 분명히 문제가 되지만 희소 배열이 죽었기 때문에 누가 신경을 쓰겠습니까? 메이저 버전을 밀어야 하는 것입니까? 버그픽스인가요?

나는 우리가 메이저 버전을 기한이 넘었다고 생각한다( 219개의 커밋 에서 많은 일이 일어났다). 2.0 릴리스와 버전 정책의 강화는 여기에서 먼 길을 갈 것입니다.

@akre54

Underscore에 대한 모든 새로운 기능 변경은 다른 사람에게는 획기적인 변경입니다.

반드시는 아닙니다.

예를 들어 _.each에 대한 모든 최근 변경 사항을 살펴보겠습니다. 원래 목록을 반환하기 위해 _.each의 반환 값을 변경할 때 충돌해야 합니까? 버그픽스인가요?

버그 수정이 아니라 개선 사항입니다. 비핵화입니까?-- _.each 의 반환 값이 의존할 가능성이 낮고 개발자가 Lo-Dash로 전환할 때 장애물로 보고한 것이 아니기 때문에 안전한 변경일 것입니다. 파손이 의심되는 경우 RC 릴리스로 물을 테스트하십시오. 변경 사항이 _.each 에서 일찍 종료할 수 있도록 하는 것이라면 개발자가 CoffeeScript를 사용할 때 해당 변경 사항에 직면하게 되므로 확실히 획기적인 변경이라고 말하고 싶습니다.

내부의 각 도우미를 외부적으로 재할당할 때 충돌해야 합니까? 누군가의 코드가 손상되었을 수 있습니까? 공개 API는 변경되지 않았습니다.

나는 그것이 문서화되지 않은 구현 세부 사항에 해당한다고 말하고 싶습니다. Underscore는 여전히 기본 메서드에 대해 분기되었기 때문에 변경 사항은 새로운 것을 허용하지 않았습니다. 이 변경 사항은 1.6.0 이후의 더 큰 변경 사항 그룹에 속하므로 2.0에 포함될 수 있습니다.

희소 배열을 피하기 위해 _.each 를 변경하고 네이티브 forEach 대신 for 루프를 사용하는 것은 분명히 일부에게는 문제가 되지만 희소 배열이 죽었기 때문에 누가 신경을 쓰겠습니까? 메이저 버전을 밀어야 하는 것입니까? 버그픽스인가요?

버그 수정으로 볼 수 있지만 확실히 주요 변경 사항입니다. 이것은 개발자 가 Lo-Dash로 전환할 때 겪는 일 중 하나입니다. Underscore가 사용 가능한 경우 기본을 사용하는 방식 때문에 희소 배열 사용을 마스크하고 개발자는 이전 브라우저에서 테스트한 경우에만 문제가 발생했습니다. 그러나 이 변경으로 개발자는 최신 브라우저에서 희소 배열 사용에 대해 더 빨리 경고를 받게 되므로 이전에 작업한 코드가 걸림돌에 부딪힐 가능성이 있습니다.

나는 우리가 메이저 버전을 기한이 넘었다고 생각합니다(219개의 커밋에서 많은 일이 일어났습니다). 2.0 릴리스와 버전 정책의 강화는 여기에서 먼 길을 갈 것입니다.

:+1:

주요 변경 사항(복수형 주요 변경 사항)

(컴퓨팅) 잠재적으로 다른 구성 요소가 실패하게 만드는 소프트웨어 시스템의 한 부분이 변경되었습니다. 여러 응용 프로그램에서 사용하는 코드의 공유 라이브러리에서 가장 자주 발생합니다.
"중단 변경 없이는 이전 항목을 수정할 수 없으므로 가져오기 라이브러리에서 이전 항목을 새 항목으로 다시 매핑하십시오."

이것 중 일부는 약간의 생각과 판단이 필요합니다. 모든 변경이 누군가의 코드를 깨뜨리는 것은 사실일 수 있지만, 모든 참가자가 개방/폐쇄 원칙을 위반을 구성하는 지침으로 사용하는 데 동의하면 모든 사람의 삶이 더 쉬워집니다.

따라서 API에 속성이나 메서드를 추가하는 것은 일반적으로 주요 변경 사항이 아닙니다(API는 확장을 위해 열려 있지만 이전 버전과 호환되지 않는 변경 사항에 대해서는 닫혀 있음).

함수 서명을 변경하려면 더 많은 생각이 필요합니다.

원래 목록을 반환하기 위해 _.each의 반환 값을 변경할 때 충돌해야 합니까?

어떤 용도로 사용되는 문서화된 API 기능이었습니까? 예를 들어, 일부 함수는 전달된 입력이 적절한 출력을 낳지 않을 때 undefined를 반환합니다. each 의 경우는 그렇지 않은 것 같습니다 ... 따라서 아마도 깨지지 않을 것입니다.

반면에 희소 배열을 피하는 것은 개발자가 의존하는 반환 값을 변경할 가능성이 더 크므로 분명히 이는 획기적인 변경이며 희소 배열을 사용하는 모든 사람은 관심을 갖습니다.

희소 배열은 ES6에서 살아남지 못할 수도 있지만 아직 죽지는 않았습니다.

@akre54
때때로 변경 사항이 중단되는지 여부에 대한 대답은 간단하지 않습니다. 이러한 경우 컨텍스트, 기록 및 데이터가 도움이 됩니다. 운이 좋게도 Lo-Dash를 새로운 기능에 대한 테스트 장소로 사용할 수 있고 Underscore에서 오는 개발자에게 어떤 변경 사항이 발생하는지 확인할 수 있습니다. Underscore는 이를 사용하여 변경의 영향에 대해 정보에 입각한 결정을 내릴 수 있습니다.

최소한 다음 semver는 주요 변경 사항이 패치 릴리스에 들어가는 것을 방지하고 개발자가 변경 사항의 영향에 대해 생각하도록 권장합니다. 모두에게 승리입니다.

@jdalton , 집단 행위. :)