Definitelytyped: META-TypeScriptの最小バージョンを更新しています

unknown追加されましたか？ 大きくなるか、家に帰ります！ DTのすべてのanyは、これらの部分の「typescriptshouldaがそれを捕まえた」バグの最大の原因です。

unknown追加されましたか？

3.0

君。 つまり、99.9％！

私たちはこれを行うべきであることに同意します。 これをやろう！

代わりに、時間をかけてゆっくりと増やしてもらえますか？ 2.1ある月、2.2次の月、というように？

各バージョンには、いくつかの小さな変更があります。 最初はゆっくりと整然と進むことで、これがどのような問題を引き起こすのかを理解しやすくなります。

メンテナンスモードのプロジェクトには、特にインフラストラクチャのコアである場合、これらの重大な変更を克服するための帯域幅がないことがよくあります。

はい、お願いします。特にnodeのタイピングは、新しい機能の欠如に悩まされており、多くの〜ハック〜回避策を使用する必要がありました。

メンテナンスモードの@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月に、typescriptの最小バージョンを18か月前のリリースに更新する予定です。それに応じて計画してください。」

@donaldpipowitch
3.0より前のユーザーのうち、まだ2.8を使用しているユーザーのクラスターが見られました。 （そしてもちろん、 @ IllusionMHが指摘しているように、条件付き型は2.8をDT型の一般的なターゲットにします。）

人々がアップグレードし続けることを望んでいるので、私たちは定期的にこの問題を再検討することを期待しています。

@galkin
技術的には、Typescriptの古いバージョンはまったくサービスされておらず、この変更はDefinitelyTypedからのサービスの停止です。 そしてもちろん、Typescriptの古いバージョンは、DTパッケージの既存のバージョンを引き続き取得できます。 彼らはただ更新を取得しません。

ただし、これは単なる技術です。 LTSのようなスケジュールを作成することをお勧めします。 しかし、私たちはまだそのようなことを始めていません。 この場合、データは事後の決定を容易にするのに十分明確でした。 将来の非推奨の適切な日付を予測する方法はまだわかりません。

Re：日付：とにかく3.7のDTインフラストラクチャを更新する必要があるため、リリースの一部として3.7のリリース日に行われます。

LTSのようなスケジュールを作成することをお勧めします。

ただエコーしたかったのですが、この種のスケジュールは本当に確かなアイデアだと思います。

@johnnyreilly私たちはMicrosoftの前例を探しています。 確かにタイプされたもののようなものはありません！

@RyanCavanaugh 、更新はありますか？

@galkin廃止予定が提案されている場合は、このスレッドに投稿してください。話し合います。

@sandersn 、これがこの問題についての私の考えです

• TypeScriptバージョンには保守終了（EOL）が必要ですか？
  もちろんはい。 作成されたすべてのTypeScriptバージョンをサポートするには、余分なリソースが必要です。
• なぜEOLスケジュールが必要なのですか？
  _ベストプラクティスは、プロジェクトの状態を前もって明確にすることです。 プロジェクトをサポートしなくなった場合、またはプロジェクトを終了する過程にある場合は、コードに遭遇する可能性のある人にそれを痛々しいほど明白にしてください_ （c） JaredSmith。
• スケジュールのベースとして何を使用する必要がありますか？
  分析？ 分析に基づくすべての決定は妥協です。 そのような決定はすべて、コミュニティ/ビジネスのどの部分をからかうかという質問に対する答えです。 WordPressにも同様の問題があり、WP / PHP/MySQLの最小バージョンでサポートする必要があります。 危険な方法です。
  依存するツールスケジュール？ Visual Code / Microsoft Azure/Angularなど。 選択肢が多すぎて簡単すぎて、新しい聖戦を始めることができません。
  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です。
  オプション2Node.jsには、EOLの前に12+18か月のポリシーがあります。 同じアプローチ、2。5年を使用できます。 長すぎることもありますが、2年以上です。
  オプション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をインストールする2.8より前のユーザーは、自分で機能しないタイプを取得する可能性があります。

進行中の議論があるので、私はこの問題を閉じるつもりはありません（そしてそれは他にメタ問題ですか？）。

@sandersnは、依存関係がそれ以上であることを通常確認するチェック（たとえば、任意のパッケージ（x =1の別のパッケージを参照するx>1の2.x）バージョンが無効になったことを意味しますか？

それがノードタイピングを前進させることの主要なブロックであるため、質問します。

@SimonSchickいいえ、無効になっていません。 >=2.8を必要とするヘッダーにのみ適用されます。

つまり、 @types/nodeを更新して3.1を要求することはできません。これは、2.8または2.4を指定するパッケージがたくさんあるためです。これは2.8として扱われます。 しかし、あなたは間違いなく@types/nodeに2.8を要求させることができます。 つまり、条件付きタイプを使用でき、古いバージョンとは異なる場合は2.8以降のセマンティクスが適用されると想定できます。

実際、デフォルトは2.8であるため、ヘッダーに必須バージョンがまったくないことは、2.8が必要であることと同じです。

@sandersn 、最小バージョンの新しいアップデートについて話してもらえますか？ 3.8がリリースされたのでいい時期だと思います。

私たちはそれを社内で議論しており、ノードスタイルの30か月のスケジュールをサポートすることに傾倒しています。 しかし、私はTypescript-VS統合チームと調整する必要があります。Typescript-VS統合チームは、new-TS-in-old-VSのサポートタイムラインを持ちたいので、まだ議論を再開しようとはしていません。 最終的に30か月になると、次の非推奨は8月になるので、少し時間があります。

更新：私はVSでTypescript-Javascriptチームと話をしましたが、彼らは2年または2。5年のスケジュールを決定しました。 彼らは、2つのどちらかを決定するのに役立ついくつかの使用状況データを収集する予定です。 私も彼らのシナリオを逆行させました-それはold-TS-in-new-VSのサポートです。

以前に収集した使用状況データ[1]に基づくと、メンテナンスの負担を軽減するために、2年間のウィンドウを使用することをお勧めします。 また、依存関係を更新することなく、重要なパッケージが6か月早く新機能の使用を開始できるようにします。 短いサポートウィンドウには、これまでに見たような実用的な欠点はありません。

ただし、ノードのスケジュールにより、代わりに2。5年のウィンドウが期待される場合があります。 長いウィンドウの他の利点はありますか？ 私が見逃しているデメリットは？

[1]
上から転載したデータ：

• テレメトリは、VS Codeユーザーの99.9％が3.0以降であることを示しています
• テレメトリは、VSユーザーの97％が3.0以降を使用していることを示しています
• DTパッケージの20％はすでに2.8以降にオプトインしています

私は短いウィンドウを好みます。 メンテナンスの負担を軽減する理由と、@sandersnで明らかにしたデータの両方を理由に。

更新していただきありがとうございます！

また、短いウィンドウの場合。

長いウィンドウは、依存関係の一部のみを更新し、タイプスクリプトは更新しないものにのみ利益をもたらします。これは、非常に小さなグループにすぎないはずです。
ほとんどの場合、人々はすべての依存関係（typescriptを含む）を定期的に更新するか、まったく更新しません。
またはその逆：2年間TypeScriptを更新することを気にしないほとんどの開発者は、おそらく新しいパッケージと新しい型定義をまったく気にしません。
したがって、これはおそらくあなたが疑っているよりもはるかに少ない人々を傷つけるでしょう-そしてそれは生態系全体が進化するのを防ぎます。

TL; DR; @sandersn 、18か月についてどう思いますか？

私の考え：

私が書いた

オプション2Node.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が非推奨になります。テレメトリで3.1を使用しているVSユーザーがかなりの数であることがわかったため、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年間のサポート期間を設けます。

2.8は2018年3月27日にリリースされたため、すぐにサポートを削除するつもりはありません。 しかし、私は次の数週間でそうします、そして、それが終わったら、私はこの問題を更新して閉じます。

＃42834のREADMEにドキュメントを追加するPRがあります。

ドキュメントの変更を＃42881でロシア語に翻訳しました

誰かが次のような翻訳の変更を手伝ってもらえますか？

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

@kingwl @ armanio123 @saschanazは、私が知っている最も複雑なTypescripterであり、これら3つの言語のネイティブスピーカーです。

（もちろん、忙しすぎる場合は、これを無視してかまいません。）

タスクは＃42834の変更の翻訳を追加していますか？

ドキュメントの変更を＃42818でロシア語に翻訳しました

＃42881です😁

はい。

タスクは＃42834の変更の翻訳を追加していますか？

ドキュメントの変更を＃42818でロシア語に翻訳しました

＃42881です😁

修理済み。 申し訳ありませんが、タイプミスをしました。

更新：3.9リリースと同時に、2.8のサポートを削除しました。

2つの理由で非推奨を延期しました。

1一般的なcovid-19遅延。

1. タイプパブリッシャーインフラストラクチャを、名前空間@definitelytyped/*に公開するモノリポジトリに切り替えている最中です。 バージョンアップデートは、そのモノレポの一部になりました。 残念ながら、私たちはまだMSオープンソースオフィスがmonorepoをオープンソースにするのを待っていますが、まもなくそうなるはずです。

4.0リリースは5月にはリリースされませんが、計画どおり5月に2.9のサポートを削除します。 新しいセットアップを使用すると、かなり簡単になるはずです。