Definitelytyped: META - Aktualisieren der minimalen TypeScript-Version

Wann wurde unknown hinzugefügt? Gehen groß oder nach Hause gehen! All die any in DT sind bei weitem die größte Quelle von Fehlern in diesen hier vorliegenden Teilen.

Wann wurde unknown hinzugefügt?

3.0

Sie. Also 99,9%!

Ich stimme zu, dass wir das tun sollten. Lass uns das machen!

Könnten Sie es bitte stattdessen langsam im Laufe der Zeit erhöhen? 2.1 in einem Monat, 2.2 im nächsten und so weiter?

Jede Version hat einige kleine Breaking Changes. Es wird einfacher zu verstehen, welche Probleme dies mit sich bringt, wenn Sie zunächst langsam und methodisch vorgehen.

Projekte im Wartungsmodus verfügen oft nicht über die Bandbreite, um diese Breaking Changes zu bewältigen, insbesondere wenn sie den Kern der Infrastruktur darstellen.

Ja bitte, insbesondere die node -Eingaben haben unter dem Mangel an neueren Features gelitten und es mussten viele Workarounds mit ~Hacks~ verwendet werden.

@JoshuaKGoldberg- Projekte im Wartungsmodus werden wahrscheinlich nicht Monat für Monat Versionen von Typdefinitionen aktualisieren, ja?

@JoshuaKGoldberg erinnert sich daran, dass ein Upgrade von DT die historischen Typdefinitionen, die bereits in npm veröffentlicht wurden, nicht entfernt. @types historische Versionen leben ewig wie Mumm-Ra.

Sie können sich auf diese verlassen, unabhängig davon, wohin DT in Bezug auf die Versionierung geht.

Macht Sinn

Hallo @RyanCavanaugh ,
Ich unterstütze eine solche Idee zu 100%. TypeScript v2.0 ist ein Blocker für ein besseres Typsystem für viele Pakete, einschließlich node .
Mir sind Transparenz und Berechenbarkeit für die Gesellschaft und die Wirtschaft wichtig . Es gibt Fragen:

• Wann ist es Ihrer Meinung nach an der Zeit, die minimal unterstützte TypeScript-Version zu ändern? Während der Veröffentlichung von TS 3.7?
• Korrigieren Sie mich, wenn ich falsch liege, aber das sieht nach dem Ende des Lebenszyklus für TypeScript-Versionen vor 2.8 aus?
• Könnten wir einen ähnlichen Zeitplan wie Node.js haben? Ein solches Dokument wird Entwicklerteams dabei helfen, Unternehmen dazu zu bringen, Entwicklungsressourcen für die Aktualisierung zu genehmigen.

Gibt es einen Grund, warum es 2.8 und keine andere Version ist? (zB 3.0 für unknown .)

In 2.8 wurden bedingte Typen eingeführt

Sehr dafür.

Bitte denken Sie, wenn Sie schon dabei sind, darüber nach, einen (halb-)formellen Zeitplan aufzustellen, damit die Community sich darauf verlassen kann, dass die Mindestversion im Laufe der Zeit vorhersehbar zunimmt. Etwas wie: „Jedes Jahr im November planen wir, die minimale Typoskript-Version auf die Veröffentlichung von 18 Monaten zuvor zu aktualisieren. Bitte planen Sie entsprechend.“

@ Donald Pipowitch
Von den Benutzern vor 3.0 sahen wir eine Gruppe von Leuten, die noch auf 2.8 waren. (Und natürlich machen bedingte Typen 2.8 zu einem beliebten Ziel für DT-Typen, wie @IllusionMH betont .)

Wir gehen davon aus, dass wir dieses Problem in regelmäßigen Abständen erneut aufgreifen werden, da wir hoffen, dass die Leute weiterhin aktualisieren.

@galkin
Technisch gesehen werden alte Versionen von Typescript überhaupt nicht gewartet, und diese Änderung ist die Einstellung des Dienstes von Definitely Typed. Und natürlich können alte Versionen von Typescript weiterhin die vorhandenen Versionen von DT-Paketen erhalten. Sie bekommen einfach keine Updates.

Allerdings ist das nur eine Formsache. Es wäre eine gute Idee für uns, einen LTS-ähnlichen Zeitplan zu erstellen. Wir haben mit so etwas aber noch nicht begonnen. In diesem Fall waren die Daten klar genug, um die nachträgliche Entscheidung zu erleichtern. Ich bin mir noch nicht sicher, wie ich ein gutes Datum für zukünftige Abwertungen vorhersagen soll.

Re: das Datum: Ich muss sowieso die DT-Infrastruktur für 3.7 aktualisieren, also wird es am Veröffentlichungstag von 3.7 als Teil des Releases passieren.

Es wäre eine gute Idee für uns, einen LTS-ähnlichen Zeitplan zu erstellen.

Ich wollte nur wiederholen, dass ich denke, dass diese Art von Zeitplan eine wirklich solide Idee ist.

@johnnyreilly , wir suchen bei Microsoft nach Präzedenzfällen. Es gibt jedoch nichts Schöneres als Definitely Typed!

@RyanCavanaugh , irgendwelche Updates?

@galkin Wenn Sie einen vorgeschlagenen Ablaufplan haben, posten Sie ihn bitte in diesem Thread, damit wir darüber diskutieren können.

@sandersn , hier sind meine Gedanken zu diesem Thema

• Benötigen wir End-of-Life (EOL) für die TypeScript-Version?
  Natürlich ja. Die Unterstützung jeder erstellten TypeScript-Version erfordert überschüssige Ressourcen.
• Warum sollten wir einen EOL-Zeitplan haben?
  _Die beste Vorgehensweise besteht darin, den Stand Ihrer Projekte offen und klar darzustellen. Wenn Sie ein Projekt nicht mehr unterstützen oder gerade dabei sind, es abzuwickeln, machen Sie das jedem, der über Ihren Code stolpern würde, schmerzlich klar_ (c) Jared Smith.
• Was sollte als Grundlage für den Zeitplan verwendet werden?
  Analytik? Jede auf Analysen basierende Entscheidung ist ein Kompromiss. Jede solche Entscheidung ist eine Antwort auf die Frage, welchen Teil der Gemeinschaft / des Geschäfts wir necken werden. WordPress hat ein ähnliches Problem, welche Mindestversion von WP/PHP/MySQL sie unterstützen sollten. Es ist ein gefährlicher Weg.
  Abhängiger Werkzeugplan? Visual Code/Microsoft Azure/Angular/usw. Zu viele Optionen und zu einfach einen neuen Heiligen Krieg beginnen.
  TC39-Prozess? Gute Option, aber TC39 führt EoL für keine Sprachfunktion ein und wird dies auch nicht tun.
  Node.js? Node.js ist ein Treiber für die JS-Community mit Release/EOL-Zeitplan. TypeScript verwendet Node.js. Ich sehe dies als beste Basis für den Zeitplan.
• Wie erstellen Sie den Zeitplan?
  Option 1. Ordnen Sie die TypeScript-Version der Node.js-Version zu und kündigen Sie ein ähnliches EOL an. Zum Beispiel hat Node.js v8 vor 2 Jahren LTS gestartet und TypeScript v2.6 wurde veröffentlicht , also ist 2019.12.31 EOL.
  Option 2 Node.js hat eine 12 + 18-monatige Richtlinie vor EOL. Wir können den gleichen Ansatz verwenden, 2,5 Jahre. Es kann zu lang sein, aber nicht weniger als 2 Jahre.
  Option 3 Vereinbaren Sie ein Treffen mit Entscheidungsträgern und teilen Sie das Ergebnis so wie es war mit der Community

Also mein Vorschlag sieht ungefähr so ​​aus:

Fassung | Freigegeben | Lebensende in 2,5 Jahren | Lebensende in 2 Jahren
-- | -- | -- | --
2.1 | Dezember 2016 | Juni 2019 | Dezember 2018
2.2 | Februar 2017 | August 2019 | Februar 2019
2.3 | April 2017 | September 2019 | April 2019
2.4 | Juni 2017 | November 2019 | Juni 2019
2.5 | August 2017 | Januar 2020 | August 2019
2.6 | Oktober 2017 | März 2020 | Oktober 2019
2.7 | Januar 2018 | Juli 2020 | Januar 2020
2.8 | März 2018 | August 2020 | Februar 2020
2.9 | Mai 2018 | Oktober 2020 | April 2020
3 | Juli 2018 | Dezember 2020 | Juni 2020
3.1 | September 2018 | März 2021 | August 2020
3.2 | November 2018 | Mai 2021 | Oktober 2020
3.3 | Januar 2019 | Juli 2021 | Dezember 2020
3.4 | März 2019 | August 2021 | Februar 2021
3.5 | Mai 2019 | Oktober 2021 | April 2021
3.6 | August 2019 | Januar 2022 | Juli 2021
3.7 | November 2019 | Mai 2022 | Oktober 2021

WOW das ist wunderbar! Danke für die Gedanken, die Sie sich hier gemacht haben.

Paar kleine Punkte:

1. Typed und Typescript sind definitiv unterschiedliche Projekte, obwohl sie den gleichen EOL-Zeitplan haben sollten.
2. Was EOL für DT bedeutet, ist oben dargelegt, aber für TS ist es nicht so klar. Soweit ich weiß, haben wir nie eine Patch-Version mit mehr als einer Nebenversion erstellt. Auf der anderen Seite haben wir den Leuten keine neueren Versionen von TS empfohlen, außer als allgemeine gute Praxis oder für bestimmte Problemumgehungen.
3. Da TS als Teil von Visual Studio ausgeliefert wird, einem kostenpflichtigen Produkt mit Supportverträgen, müssen wir möglicherweise eine VS-spezifische Erweiterung für den definierten Open-Source-Supportzeitraum definieren. Dies sollte die Open-Source-Community jedoch nicht beeinträchtigen.

@DanielRosenwasser kannst du dir das mal ansehen, wenn du Zeit hast?

2,8 ist jetzt das neue Minimum. 2.0 - 2.7 werden nicht mehr getestet und die ts2.0 - ts2.7-Tags werden nicht mehr auf bestehenden @types/* -Paketen aktualisiert. Benutzer vor Version 2.8, die @types/*@latest installieren, erhalten möglicherweise Typen, die für sie nicht funktionieren.

Ich werde dieses Thema nicht schließen, da es eine laufende Diskussion gibt (und es ist außerdem ein Meta-Problem?).

@sandersn bedeutet das, dass die Überprüfung, die normalerweise überprüft, ob eine Abhängigkeit eine größere oder gleiche Version hat (z. B. ein beliebiges Paket (2.x mit x > 1, das auf ein anderes Paket mit x = 1 verweist), jetzt deaktiviert ist?

Fragen, weil dies eine große Blockade für das Vorwärtsbewegen von Node-Eingaben ist.

@SimonSchick nein, es ist nicht deaktiviert; es gilt nur für Header, die >=2.8 erfordern.

Mit anderen Worten, Sie können @types/node nicht so aktualisieren, dass es 3.1 erfordert, weil es viele Pakete gibt, die 2.8 oder 2.4 spezifizieren – was als 2.8 behandelt wird. Aber Sie können jetzt definitiv @types/node 2.8 verlangen. Das bedeutet, dass Sie bedingte Typen verwenden können, und Sie können davon ausgehen, dass die Semantik von 2.8+ dort gilt, wo sie sich von alten Versionen unterscheidet.

Tatsächlich ist der Standardwert 2.8, sodass das Fehlen einer erforderlichen Version im Header gleichbedeutend mit dem Erfordernis von 2.8 ist.

@sandersn , könnten wir über ein neues Update der Minimalversion sprechen? Ich denke, es ist ein guter Zeitpunkt, weil 3.8 veröffentlicht wurde.

Wir haben intern darüber diskutiert und neigen dazu, den 30-Monats-Zeitplan im Node-Stil zu unterstützen. Aber ich muss mich mit dem Typescript-VS-Integrationsteam abstimmen, das einen Support-Zeitplan für New-TS-in-Old-VS haben möchte, daher habe ich noch nicht versucht, die Diskussion wieder aufzunehmen. Wenn wir bei 30 Monaten landen, wird die nächste Einstellung im August sein, also haben wir ein wenig Zeit.

Update: Ich habe mit dem Typescript-Javascript-Team von VS gesprochen und sie haben sich entweder für einen 2-Jahres- oder einen 2,5-Jahres-Zeitplan entschieden. Sie werden einige Nutzungsdaten sammeln, um ihnen bei der Entscheidung zwischen den beiden zu helfen. Ich habe auch ihr Szenario rückwärts verstanden – es ist Unterstützung für Old-TS-in-New-VS.

Basierend auf unseren zuvor gesammelten Nutzungsdaten [1] bevorzuge ich ein 2-Jahres-Fenster, einfach um den Wartungsaufwand zu reduzieren. Außerdem können wichtige Pakete 6 Monate früher mit der Verwendung neuer Funktionen beginnen, ohne dass abhängige Elemente aktualisiert werden müssen. Ein kurzes Support-Fenster hat keine praktischen Nachteile, die ich bisher gesehen habe.

Der Zeitplan des Knotens kann jedoch dazu führen, dass die Leute stattdessen ein 2,5-Jahres-Fenster erwarten. Gibt es weitere Vorteile des längeren Fensters? Nachteile, die ich übersehe?

[1]
Daten von oben nachgedruckt:

• Telemetrie zeigt, dass 99,9 % der VS Code-Benutzer 3.0 oder neuer sind
• Telemetrie zeigt, dass 97 % der VS-Benutzer 3.0 oder neuer verwenden
• 20 % der DT-Pakete haben sich bereits für 2.8 oder neuer entschieden

Ich bevorzuge ein kürzeres Fenster; sowohl aus Gründen der Reduzierung des Wartungsaufwands als auch angesichts der Daten, die Sie @sandersn aufgedeckt haben.

Danke für das Update!

Auch für ein kürzeres Fenster.

Ein langes Fenster würde nur denen zugutekommen, die nur einen Teil ihrer Abhängigkeiten aktualisieren, aber niemals typisieren, und das sollte nur eine sehr kleine Gruppe sein.
Meistens aktualisieren die Leute entweder regelmäßig alle ihre Abhängigkeiten (einschließlich Typoskript) oder gar keine.
Oder umgekehrt: Die meisten Entwickler, die sich seit zwei Jahren nicht die Mühe gemacht haben, ihr TypeScript zu aktualisieren, interessieren sich wahrscheinlich überhaupt nicht für frische Pakete und frische Typdefinitionen.
Das würde also wahrscheinlich viel weniger Menschen schaden, als Sie vielleicht vermuten – und es hält das gesamte Ökosystem davon ab, sich weiterzuentwickeln.

TL;DR; @sandersn , was denkst du über 18 Monate?

Meine Gedanken :

Ich schrieb

Option 2 Node.js hat eine 12 + 18-monatige Richtlinie vor EOL. Wir können den gleichen Ansatz verwenden, 2,5 Jahre. Es kann zu lang sein, aber nicht weniger als 2 Jahre.

aber ich kann mich nicht erinnern, warum ich dachte, dass 2 Jahre der richtige Zeitraum sind. Ich kann diese 2 Jahre nicht logisch belegen. Jetzt, mit einem frischen Verstand, scheint es mir, dass es ..., but not less 18 months hätte geben sollen.

Jede vom LTS-Plan abgedeckte Hauptversion wird für einen Zeitraum von 12 Monaten ab dem Datum, an dem sie in die LTS-Abdeckung aufgenommen wird, aktiv gewartet. Nach diesen 12 Monaten aktiver Unterstützung wechselt die Hauptversion für weitere 18 Monate in den Wartungsmodus. Vor Node.js 12 betrug der aktive Zeitraum 18 Monate und der Wartungszeitraum 12 Monate. (c) Node.js-Versionsplan

Motivation : Jede TypeScipt-Version wird zuerst als rc/beta veröffentlicht. Jede stabile Version hat also vom ersten Tag an einen Wartungsmodus und 18 Monate sind gut genug.

Das ist logisch. Aber wenn wir 18 Monate als Zeitfenster verwenden, würden wir 3.1 im März 2020 verwerfen. Angesichts der Tatsache, dass unsere Telemetrie zeigt, dass eine beträchtliche Anzahl von VS-Benutzern immer noch 3.1 verwenden, denke ich nicht, dass 3.1 bereits verworfen werden sollte.

Es ist jedoch möglich, dass sich diese Zahlen seit Ende Oktober geändert haben. Ich werde herausfinden, was sie aktuell sind.

Die Nutzungszahlen für 3.1 sind in VS seit Ende Oktober nicht mehr so ​​stark zurückgegangen. Interessanterweise konzentrieren sich 95 % der Nutzung auf 3.9 - 3.4.

Ich denke, 3.1 wird immer noch so oft verwendet, weil VS es Ihnen ermöglicht, beim Herunterladen von Updates das Aktualisieren von Typoskript zu vermeiden, aber ich bin mir nicht sicher. Unabhängig davon wird dieses Verhalten wahrscheinlich in zukünftigen Versionen von VS und anderen IDEs, die nicht so oft aktualisiert werden, fortgesetzt.

Zusammenfassend lässt sich sagen, dass wir zur Unterstützung von 98 % der VS-Benutzer ein 2-Jahres-Fenster benötigen. Um 95 % zu unterstützen, benötigen wir nur ein 1-Jahres-Fenster! Aber es macht nicht viel Sinn, irgendetwas dazwischen zu haben.

Ich unterstütze immer noch 2 Jahre basierend auf diesen Daten.

Für mich sieht es so aus, als wäre die Diskussion hier beendet. Ich werde mit einem 2-jährigen Support-Fenster gehen.

2.8 wurde am 27. März 2018 veröffentlicht, daher werde ich die Unterstützung nicht sofort entfernen. Aber ich werde dies in den nächsten Wochen tun, und ich werde dieses Problem aktualisieren und schließen, wenn es fertig ist.

Ich habe eine PR, die der README-Datei unter #42834 Dokumentation hinzufügt.

Ich habe die Dokumentationsänderungen unter #42881 ins Russische übersetzt

Könnte jemand bei Übersetzungsänderungen helfen in:

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

@kingwl @armanio123 @saschanaz sind die engagiertesten Schreibmaschinen, die ich kenne, die Muttersprachler für diese drei Sprachen sind.

(Wenn Sie zu beschäftigt sind, können Sie dies natürlich ignorieren.)

Fügt die Aufgabe eine Übersetzung für Änderungen in #42834 hinzu?

Ich habe die Dokumentationsänderungen unter #42818 ins Russische übersetzt

Es ist #42881 😁

Jawohl.

Fügt die Aufgabe eine Übersetzung für Änderungen in #42834 hinzu?

Ich habe die Dokumentationsänderungen unter #42818 ins Russische übersetzt

Es ist #42881 😁

Fest. Entschuldigung, ich habe den Tippfehler gemacht.

Update: Gleichzeitig mit der Veröffentlichung von 3.9 habe ich gerade die Unterstützung für 2.8 entfernt.

Ich habe die Abwertung aus zwei Gründen hinausgezögert.

1 Allgemeine Covid-19-Verzögerung.

1. Wir sind dabei, die Types-Publisher-Infrastruktur auf ein Monorepo umzustellen, das im Namespace @definitelytyped/* veröffentlicht. Das Versionsupdate ist nun Teil des Monorepos. Leider warten wir immer noch darauf, dass MS Open Source Office das Monorepo Open Source macht, aber es sollte bald soweit sein.

Auch wenn die Version 4.0 nicht im Mai erscheinen wird, werde ich die Unterstützung für 2.9 wie geplant im Mai entfernen. Mit dem neuen Setup sollte es um einiges einfacher sein.