Definitelytyped: META - 최소 TypeScript 버전 업데이트

unknown 는 언제 추가되었습니까? 크게 가거나 집에 가십시오! DT의 모든 any 는 여기 이 부분에서 "typescript가 잡아야 하는" 버그의 가장 큰 소스입니다.

unknown 는 언제 추가되었습니까?

3.0

너. 그래서 99.9%!

나는 우리가 이것을 해야 한다는 데 동의합니다. 해보자!

대신 시간이 지남에 따라 천천히 늘릴 수 있습니까? 2.1 한 달, 2.2 다음 달, 등등?

각 버전에는 약간의 주요 변경 사항이 있습니다. 처음에는 천천히 그리고 체계적으로 진행하면 이것이 어떤 문제를 야기하는지 이해하는 것이 더 쉬울 것입니다.

유지 관리 모드의 프로젝트는 특히 인프라의 핵심인 경우 이러한 주요 변경 사항을 극복할 대역폭이 없는 경우가 많습니다.

예, 특히 node 타이핑은 새로운 기능의 부족으로 인해 어려움을 겪었고 많은 ~hacks~ 해결 방법을 사용해야 했습니다.

유지 관리 모드의 @JoshuaKGoldberg 프로젝트는 매달 유형 정의 버전을 업그레이드하지 않을 것입니다.

@JoshuaKGoldberg 는 DT를 업그레이드해도 npm에 이미 게시된 기록 유형 정의가 제거되지 않는다는 것을 기억합니다. @types 역사적인 버전은 Mumm-Ra처럼 영원히 살아 있습니다.

DT가 버전 관리를 수행하는 위치에 관계없이 해당 항목에 의존할 수 있습니다.

말이된다

안녕하세요 @RyanCavanaugh ,
나는 그런 생각을 100% 지지한다. TypeScript v2.0은 node 를 포함한 많은 패키지에 대한 더 나은 유형 시스템을 위한 차단기입니다.
저는 커뮤니티와 비즈니스를 위한 투명성과 예측 가능성에 관심을 갖고 있습니다. 질문이 있습니다:

• 최소 지원 TypeScript 버전을 언제 변경하는 것이 좋다고 생각하십니까? 릴리스 TS 3.7 동안?
• 내가 틀렸다면 정정해 주세요. 하지만 이것은 2.8 이전의 TypeScript 버전에서 수명이 다한 것처럼 보입니까?
• Node.js 와 비슷한 일정을 가질 수 있습니까? 이러한 문서는 개발 팀이 업데이트를 위해 개발 리소스를 승인하도록 비즈니스를 추진하는 데 도움이 됩니다.

다른 버전이 아닌 2.8인 이유가 있습니까? (예: unknown 의 경우 3.0 )

2.8은 조건부 유형이 도입된 때입니다.

크게 찬성합니다.

시간이 지남에 따라 예상대로 증가하는 최소 버전을 커뮤니티가 신뢰할 수 있도록 (준)공식 일정을 설정하는 것을 고려하십시오. "매년 11월에 우리는 최소 타이프스크립트 버전을 18개월 전의 릴리스로 업데이트할 계획입니다. 그에 따라 계획하십시오."

@donaldpipowitch
3.0 이전 사용자 중에서 우리는 여전히 2.8을 사용하는 사람들을 보았습니다. (물론 @IllusionMH 가 지적한 것처럼 조건부 유형은 2.8을 DT 유형의 인기 있는 대상으로 만듭니다.)

우리는 사람들이 계속 업그레이드하기를 희망하기 때문에 이 문제를 주기적으로 재검토할 것으로 예상합니다.

@갈킨
기술적으로 Typescript의 이전 버전은 전혀 서비스되지 않으며, 이번 변경으로 확실히 Typed에서 서비스가 중단되었습니다. 물론 이전 버전의 Typescript는 기존 버전의 DT 패키지를 계속 사용할 수 있습니다. 그들은 단지 업데이트를 받지 못할 것입니다.

그러나 그것은 단지 기술입니다. LTS와 같은 일정을 만드는 것이 좋습니다. 우리는 아직 그런 일을 시작하지 않았습니다. 이 경우 데이터는 사후 결정을 쉽게 할 수 있을 만큼 명확했습니다. 향후 사용 중단에 대한 적절한 날짜를 예측하는 방법을 아직 잘 모르겠습니다.

Re: 날짜: 어쨌든 3.7용 DT 인프라를 업데이트해야 하므로 릴리스의 일부로 3.7 릴리스 날짜에 업데이트됩니다.

LTS와 같은 일정을 만드는 것이 좋습니다.

나는 이런 종류의 일정이 정말 확실한 아이디어라고 생각합니다.

@johnnyreilly 우리는 선례를 위해 Microsoft를 둘러보고 있습니다. 확실히 유형이 지정된 것과 같은 것은 없습니다!

@RyanCavanaugh , 업데이트가 있습니까?

@galkin 제안된 지원 중단 일정이 있는 경우 이 스레드에 게시하여 논의할 수 있도록 하십시오.

@sandersn , 이 문제에 대한 내 생각은 다음과 같습니다.

• TypeScript 버전에 EOL(단종)이 필요합니까?
  물론 예. 생성된 모든 TypeScript 버전을 지원하려면 잉여 리소스가 필요합니다.
• EOL 일정이 있어야 하는 이유는 무엇입니까?
  _가장 좋은 방법은 프로젝트 상태를 사전에 명확하게 밝히는 것입니다. 더 이상 프로젝트를 지원하지 않거나 프로젝트를 마무리하는 중이라면 코드를 우연히 발견한 사람에게 고통스러울 정도로 명백하게 알리십시오_ (c) Jared Smith.
• 일정의 기준으로 무엇을 사용해야 합니까?
  해석학? 분석에 기반한 모든 결정은 타협입니다. 그러한 모든 결정은 커뮤니티/비즈니스의 어떤 부분을 놀릴 것인지에 대한 질문에 대한 답변입니다. WordPress에는 지원해야 하는 WP/PHP/MySQL의 최소 버전 과 유사한 문제가 있습니다. 위험한 방법입니다.
  종속 도구 일정? 비주얼 코드/마이크로소프트 애저/앵귤러/등. 너무 많은 옵션과 너무 쉬운 새로운 신성한 전쟁을 시작합니다.
  TC39 프로세스? 좋은 옵션이지만 TC39는 어떤 언어 기능에도 EoL을 도입하지 않으며 앞으로도 도입하지 않을 것입니다.
  Node.js? Node.js는 릴리스/EOL 일정이 있는 JS 커뮤니티용 드라이버입니다. TypeScript는 Node.js를 사용합니다. 나는 이것이 일정을 위한 최고의 기초라고 본다.
• 일정은 어떻게 만드나요?
  옵션 1. TypeScript 버전을 Node.js 버전과 연결하고 유사한 EOL을 발표합니다. 예를 들어 2년 전 Node.js v8이 LTS를 시작 했고 TypeScript v2.6이 출시 되었으므로 2019.12.31은 EOL입니다.
  옵션 2 Node.js에는 EOL 전 12+18개월 정책이 있습니다. 2.5년이라는 동일한 접근 방식을 사용할 수 있습니다. 너무 길 수 있지만 2년 미만은 아닙니다.
  Option 3 의사결정자와 회의를 하고 결과를 그대로 커뮤니티 에 공유

내 제안은 다음과 같습니다.

버전 | 출시 | 2.5년 후 수명 종료 | 2년 후 수명 종료
-- | -- | -- | --
2.1 | 2016년 12월 | 2019년 6월 | 2018년 12월
2.2 | 2017년 2월 | 2019년 8월 | 2019년 2월
2.3 | 2017년 4월 | 2019년 9월 | 2019년 4월
2.4 | 2017년 6월 | 2019년 11월 | 2019년 6월
2.5 | 2017년 8월 | 2020년 1월 | 2019년 8월
2.6 | 2017년 10월 | 2020년 3월 | 2019년 10월
2.7 | 2018년 1월 | 2020년 7월 | 2020년 1월
2.8 | 2018년 3월 | 2020년 8월 | 2020년 2월
2.9 | 2018년 5월 | 2020년 10월 | 2020년 4월
3 | 2018년 7월 | 2020년 12월 | 2020년 6월
3.1 | 2018년 9월 | 2021년 3월 | 2020년 8월
3.2 | 2018년 11월 | 2021년 5월 | 2020년 10월
3.3 | 2019년 1월 | 2021년 7월 | 2020년 12월
3.4 | 2019년 3월 | 2021년 8월 | 2021년 2월
3.5 | 2019년 5월 | 2021년 10월 | 2021년 4월
3.6 | 2019년 8월 | 2022년 1월 | 2021년 7월
3.7 | 2019년 11월 | 2022년 5월 | 2021년 10월

와우, 이것은 놀랍습니다! 생각해주셔서 감사합니다.

몇 가지 작은 점:

1. 확실히 Typed와 Typescript는 EOL 일정이 같아야 하지만 다른 프로젝트입니다.
2. DT에 대한 EOL의 의미는 위에 설명되어 있지만 TS에 대해서는 명확하지 않습니다. 내가 아는 한 패치 버전을 하나 이상의 부 버전으로 만든 적이 없습니다. 반면에 일반적인 모범 사례나 특정 해결 방법을 제외하고 사람들에게 최신 버전의 TS를 권장하지 않았습니다.
3. TS는 지원 계약이 있는 유료 제품인 Visual Studio의 일부로 제공되므로 정의된 오픈 소스 지원 기간에 대해 VS 관련 확장을 정의해야 할 수 있습니다. 이것은 오픈 소스 커뮤니티에 영향을 미치지 않아야 합니다.

@DanielRosenwasser 시간 나실 때 이거 봐주시겠습니까?

2.8은 이제 새로운 최소값입니다. 2.0 - 2.7은 더 이상 테스트되지 않으며 ts2.0 - ts2.7 태그는 기존 @types/* 패키지에서 더 이상 업데이트되지 않습니다. @types/*@latest 를 설치하는 Pre-2.8 사용자는 작동하지 않는 유형을 얻을 수 있습니다.

진행 중인 토론이 있기 때문에 이 문제를 닫지 않겠습니다(게다가 메타 문제인가요?).

@sandersn 은 일반적으로 종속성이 크거나 같은지 확인하는 검사(예: 임의 패키지(x가 1인 다른 패키지를 참조하는 x > 1이 있는 2.x) 버전이 이제 비활성화되었음을 의미합니까?

그것이 노드 타이핑을 앞으로 나아가는 주요 차단이기 때문에 묻습니다.

@SimonSchick 아니요, 비활성화되지 않았습니다. >=2.8 가 필요한 헤더에만 적용됩니다.

즉, 2.8 또는 2.8로 처리되는 2.8 또는 2.4를 지정하는 패키지가 많기 때문에 @types/node 를 3.1을 요구하도록 업데이트할 수 없습니다. 그러나 지금은 @types/node 에 2.8이 필요합니다. 즉, 조건부 유형을 사용할 수 있으며 이전 버전과 다른 경우 2.8+ 의미 체계가 적용된다고 가정할 수 있습니다.

실제로 기본값은 2.8이므로 헤더에 필요한 버전이 전혀 없는 것은 2.8이 필요한 것과 같습니다.

@sandersn , 최소 버전의 새로운 업데이트에 대해 이야기할 수 있습니까? 3.8이 출시되었기 때문에 좋은 시기라고 생각합니다.

내부적으로 논의했으며 노드 스타일의 30개월 일정을 지원하는 방향으로 기울고 있습니다. 그러나 new-TS-in-old-VS에 대한 지원 일정을 갖고 싶어하는 Typescript-VS 통합 팀과 조정해야 하므로 아직 토론을 다시 시작하지 않았습니다. 30개월로 끝나면 다음 지원 중단은 8월이 되므로 약간의 시간이 있습니다.

업데이트: VS에서 Typescript-Javascript 팀과 이야기를 나누었고 2년 또는 2.5년 일정으로 결정했습니다. 그들은 둘 사이에서 결정하는 데 도움이 되는 몇 가지 사용 데이터를 수집할 것입니다. 나는 또한 그들의 시나리오를 거꾸로 가지고 있습니다. 그것은 old-TS-in-new-VS에 대한 지원입니다.

이전에 수집한 사용 데이터[1]에 따르면 유지 관리 부담을 줄이기 위해 2년 기간을 선호합니다. 또한 중요한 패키지가 종속 항목을 업데이트하지 않고도 6개월 더 빨리 새로운 기능을 사용할 수 있습니다. 짧은 지원 창에는 지금까지 본 실용적인 단점이 없습니다.

그러나 노드의 일정으로 인해 사람들은 대신 2.5년의 기간을 예상할 수 있습니다. 더 긴 창의 다른 이점이 있습니까? 내가 놓치고 있는 단점?

[1]
위에서 재인쇄된 데이터:

• 원격 측정은 VS Code 사용자의 99.9%가 3.0 이상임을 나타냅니다.
• 원격 측정은 VS 사용자의 97%가 3.0 이상임을 나타냅니다.
• 20%의 DT 패키지가 이미 2.8 이상을 선택했습니다.

나는 더 짧은 창을 선호합니다. 유지 관리 부담을 줄이고 @sandersn에서 발견한 데이터를 제공하기 때문입니다.

업데이트해주셔서 감사합니다!

또한 더 짧은 창을 위해.

긴 창은 종속성의 일부만 업데이트하지만 타이프스크립트는 업데이트하지 않는 사용자에게만 이익이 되며 매우 작은 그룹이어야 합니다.
대부분의 경우 사람들은 모든 종속성(타입스크립트 포함)을 정기적으로 업데이트하거나 전혀 업데이트하지 않습니다.
또는 반대로: 2년 동안 TypeScript를 업데이트하지 않은 대부분의 개발자는 아마도 새로운 패키지와 새로운 유형 정의에 대해 전혀 신경 쓰지 않을 것입니다.
따라서 이것은 아마도 당신이 의심하는 것보다 훨씬 적은 사람들에게 피해를 줄 것이며 전체 생태계가 진화하는 것을 막습니다.

TL;DR; @sandersn , 18개월에 대해 어떻게 생각하세요?

내 생각 :

나는 썼다

옵션 2 Node.js에는 EOL 전 12+18개월 정책이 있습니다. 2.5년이라는 동일한 접근 방식을 사용할 수 있습니다. 너무 길 수 있지만 2년 미만은 아닙니다.

근데 왜 2년이 적당한 시기라고 생각했는지 기억이 안나네요. 나는 이것을 2년 동안 논리적으로 입증할 수 없다. 이제 신선한 마음으로 ..., but not less 18 months 가 있어야 했던 것 같습니다.

LTS 플랜이 적용되는 모든 주요 버전은 LTS 적용 범위에 들어간 날짜로부터 12개월 동안 적극적으로 유지됩니다. 12개월간의 적극적인 지원 이후, 주요 버전은 추가로 18개월 동안 "유지 관리" 모드로 전환됩니다. Node.js 12 이전에는 활성 기간이 18개월, 유지 관리 기간이 12개월이었습니다. (c) Node.js 출시 계획

동기 : 모든 TypeScipt 버전은 먼저 rc/beta로 출시됩니다. 따라서 모든 안정적인 릴리스에는 첫날부터 유지 관리 모드가 있으며 18개월이면 충분합니다.

그것은 논리적입니다. 그러나 18개월을 기간으로 사용하는 경우 2020년 3월에 3.1을 더 이상 사용하지 않을 것입니다. 원격 측정에서 상당수의 VS 사용자가 여전히 3.1을 사용하는 것으로 나타났으므로 3.1이 아직 사용되지 않아야 한다고 생각하지 않습니다.

그러나 10월 말부터 그 수치가 변경되었을 가능성이 있습니다. 나는 그들이 현재 무엇인지 알아낼 것입니다.

3.1의 ​​사용 횟수는 10월 말 이후 VS에서 그렇게 많이 줄어들지 않았습니다. 흥미롭게도 사용량의 95%가 3.9 - 3.4에 집중되어 있습니다.

VS를 사용하면 업데이트를 다운로드할 때 typescript 업데이트를 피할 수 있기 때문에 3.1이 여전히 많이 사용된다고 생각하지만 확실하지 않습니다. 그럼에도 불구하고 이 동작은 향후 버전의 VS와 자주 업데이트되지 않는 다른 IDE에서 계속될 가능성이 높습니다.

요약하면 VS 사용자의 98%를 지원하려면 2년의 기간이 필요합니다. 95%를 지원하려면 1년의 기간만 있으면 됩니다! 그러나 그 사이에 아무 의미가 없습니다.

나는 여전히 그 데이터를 기반으로 2년을 지지한다.

여기서 토론이 끝난 것 같습니다. 2년 지원 기간으로 가겠습니다.

2018년 3월 27일에 릴리스된 2.8 이므로 지원을 즉시 제거하지 않겠습니다. 그러나 앞으로 몇 주 안에 그렇게 할 것이며 완료되면 이 문제를 업데이트하고 닫을 것입니다.

#42834의 README에 문서를 추가하는 PR이 있습니다.

문서 변경 사항을 #42881에서 러시아어로 번역했습니다.

누군가 다음으로 번역 변경을 도울 수 있습니까?

• README.cn.md
• README.es.md
• README.ko.md

@kingwl @armanio123 @saschanaz 는 내가 아는 이 세 언어의 원어민인 Typescripters에 가장 많이 관여합니다.

(물론 너무 바쁘다면 무시하셔도 됩니다.)

작업이 #42834의 변경 사항에 대한 번역을 추가합니까?

문서 변경 사항을 #42818에서 러시아어로 번역했습니다.

#42881입니다 😁

네.

작업이 #42834의 변경 사항에 대한 번역을 추가합니까?

문서 변경 사항을 #42818에서 러시아어로 번역했습니다.

#42881입니다 😁

결정된. 죄송합니다, 제가 오타를 만들었습니다.

업데이트: 3.9 릴리스와 동시에 2.8에 대한 지원을 제거했습니다.

두 가지 이유로 지원 중단을 연기했습니다.

1 일반 코로나19 지연.

1. 우리는 type-publisher 인프라를 @definitelytyped/* 네임스페이스에 게시하는 monorepo로 전환하는 중입니다. 버전 업데이트는 이제 해당 monorepo의 일부입니다. 불행히도 우리는 여전히 MS 오픈 소스 사무실에서 monorepo 오픈 소스를 만들기를 기다리고 있지만 곧 그렇게 될 것입니다.

4.0 릴리스가 5월에 나오지는 않겠지만 계획대로 5월에 2.9에 대한 지원을 제거할 것입니다. 새로운 설정으로 훨씬 쉬워야 합니다.