Definitelytyped: META - Mise à jour de la version minimale de TypeScript

Quand unknown a-t-il été ajouté ? Allez grand ou rentrez chez vous ! Tous les any dans DT sont de loin la plus grande source de bogues "dactylographié aurait dû l'attraper" dans ces parties ici.

Quand unknown a-t-il été ajouté ?

3.0

toi. Donc, 99,9 % !

Je suis d'accord que nous devrions le faire. Faisons cela!

S'il vous plaît, pourriez-vous plutôt l'augmenter lentement au fil du temps ? 2.1 un mois, 2.2 le suivant, et ainsi de suite ?

Chaque version a quelques petits changements de rupture. Il sera plus facile de comprendre les problèmes que cela apporte en y allant lentement et méthodiquement au début.

Les projets en mode maintenance n'ont souvent pas la bande passante nécessaire pour surmonter ces changements de rupture, surtout s'ils sont au cœur de l'infrastructure.

Oui, s'il vous plaît, les saisies node en particulier ont souffert du manque de fonctionnalités plus récentes et de nombreuses solutions de contournement ~ hacks ~ ont dû être utilisées.

Les projets @JoshuaKGoldberg en mode maintenance ne mettront probablement pas à jour les versions des définitions de type mois après mois, n'est-ce pas ?

@JoshuaKGoldberg rappelez-vous que la mise à niveau de DT ne supprime pas les définitions de type historiques qui ont déjà été publiées sur npm. Les versions historiques @types vivent pour toujours comme Mumm-Ra.

Vous pourrez compter sur ceux-ci, quel que soit l'endroit où DT va en termes de version.

logique

Salut @RyanCavanaugh ,
Je soutiens cette idée à 100%. TypeScript v2.0 est un bloqueur pour un meilleur système de type pour de nombreux packages, y compris node .
Je me soucie de la transparence et de la prévisibilité pour la communauté et les entreprises . Il y a des questions:

• Quand pensez-vous qu'il est temps de changer la version minimale de TypeScript prise en charge ? Pendant la version TS 3.7 ?
• Corrigez-moi si je me trompe, mais cela ressemble à la fin de vie des versions TypeScript avant 2.8 ?
• Pourrions-nous avoir un calendrier similaire à Node.js ? Un tel document aidera les équipes de développement à pousser les entreprises à approuver les ressources de développement pour la mise à jour.

Une raison pour laquelle c'est 2.8 et pas une version différente ? (Par exemple 3.0 pour unknown .)

2.8 est le moment où les types conditionnels ont été introduits

Fortement en faveur.

S'il vous plaît, pendant que vous y êtes, envisagez de mettre en place un calendrier (semi-) formel afin que la communauté puisse compter sur l'augmentation prévisible de la version minimale au fil du temps. Quelque chose comme : "Chaque année en novembre, nous prévoyons de mettre à jour la version minimale du manuscrit à la version de 18 mois avant. Veuillez planifier en conséquence."

@donaldpipowitch
Parmi les utilisateurs pré-3.0, nous avons vu un groupe de personnes encore sur 2.8. (Et, bien sûr, les types conditionnels font de 2.8 une cible populaire pour les types DT, comme le souligne @IllusionMH .)

Nous prévoyons de revoir ce problème périodiquement car nous espérons que les gens continueront à mettre à niveau.

@galkin
Techniquement, les anciennes versions de Typescript ne sont pas du tout desservies, et ce changement est l'arrêt du service de Definitely Typed. Et bien sûr, les anciennes versions de Typescript peuvent continuer à obtenir les versions existantes des packages DT. Ils ne recevront tout simplement pas de mises à jour.

Cependant, ce n'est qu'un détail technique. Ce serait une bonne idée pour nous de produire un calendrier de type LTS. Nous n'avons pas encore commencé quoi que ce soit de ce genre. Dans ce cas, les données étaient suffisamment claires pour faciliter la décision a posteriori. Je ne sais pas encore comment prédire une bonne date pour les dépréciations futures.

Re : la date : Je dois de toute façon mettre à jour l'infrastructure DT pour la version 3.7, donc cela se produira le jour de la sortie de la version 3.7 dans le cadre de la version.

Ce serait une bonne idée pour nous de produire un calendrier de type LTS.

Je voulais juste faire écho, je pense que ce genre de calendrier est une idée vraiment solide.

@johnnyreilly, nous cherchons autour de Microsoft un précédent. Il n'y a rien de tel que Definitely Typé !

@RyanCavanaugh , des mises à jour ?

@galkin si vous avez un calendrier de dépréciation proposé, veuillez le publier sur ce fil afin que nous puissions en discuter.

@sandersn , voici mes réflexions sur cette question

• Avons-nous besoin de la fin de vie (EOL) pour la version TypeScript ?
  Bien sûr que oui. La prise en charge de chaque version de TypeScript créée nécessite des ressources excédentaires.
• Pourquoi devrions-nous avoir un calendrier EOL ?
  _La meilleure pratique consiste à être franc et clair avec l'état de vos projets. Si vous ne soutenez plus un projet, ou si vous êtes en train de le terminer, faites en sorte que cela soit douloureusement évident pour quiconque tomberait sur votre code_ (c) Jared Smith.
• Qu'est-ce qui devrait être utilisé comme base pour le calendrier ?
  Analytique? Chaque décision basée sur l'analyse est un compromis. Chacune de ces décisions est une réponse à la question de savoir quelle partie de la communauté / entreprise allons-nous taquiner. WordPress a un problème similaire sur la version minimale de WP/PHP/MySQL qu'il doit prendre en charge. C'est une voie dangereuse.
  Calendrier d'outils dépendant ? Code visuel/Microsoft Azure/Angular/etc. Trop d'options et trop facile de commencer une nouvelle guerre sainte.
  Processus TC39 ? Bonne option, mais TC39 n'introduit pas et n'introduira pas EoL pour aucune fonctionnalité de langue.
  Node.js ? Node.js est un pilote pour la communauté JS avec un calendrier de publication/EOL. TypeScript utilise Node.js. Je vois cela comme la meilleure base pour le calendrier.
• Comment créer le planning ?
  Option 1. Associez la version TypeScript à la version Node.js et annoncez une EOL similaire. Par exemple, il y a 2 ans, Node.js v8 a démarré LTS et TypeScript v2.6 a été publié , donc 2019.12.31 est EOL.
  L'option 2 Node.js a une politique de 12 + 18 mois avant la fin de vie. Nous pouvons utiliser la même approche, 2,5 ans. Cela peut être trop long, mais pas moins de 2 ans.
  Option 3 Faire une réunion avec les décideurs et partager avec la communauté le résultat tel qu'il a été

Donc ma proposition ressemble à ça :

version | Libéré | Fin de vie dans 2,5 ans | Fin de vie dans 2 ans
-- | -- | -- | --
2.1 | décembre 2016 | juin 2019 | Décembre 2018
2.2 | février 2017 | août 2019 | Février 2019
2.3 | avril 2017 | septembre 2019 | Avril 2019
2.4 | juin 2017 | novembre 2019 | Juin 2019
2.5 | août 2017 | janvier 2020 | Août 2019
2.6 | octobre 2017 | mars 2020 | Octobre 2019
2.7 | janvier 2018 | juillet 2020 | Janvier 2020
2.8 | mars 2018 | août 2020 | Février 2020
2.9 | Mai 2018 | octobre 2020 | Avril 2020
3 | juillet 2018 | décembre 2020 | juin 2020
3.1 | septembre 2018 | mars 2021 | Août 2020
3.2 | novembre 2018 | mai 2021 | Octobre 2020
3.3 | janvier 2019 | juillet 2021 | Décembre 2020
3.4 | mars 2019 | août 2021 | Février 2021
3.5 | Mai 2019 | octobre 2021 | avril 2021
3.6 | août 2019 | janvier 2022 | juillet 2021
3.7 | novembre 2019 | mai 2022 | Octobre 2021

Waouh, c'est incroyable ! Merci pour la réflexion que vous y avez consacrée.

Quelques petits points :

1. Certainement Typed et Typescript sont des projets différents, bien qu'ils doivent avoir le même calendrier EOL.
2. Ce que signifie EOL pour DT est expliqué ci-dessus, mais ce n'est pas aussi clair pour TS. Nous n'avons jamais créé de version patch plus d'une version mineure à ma connaissance. D'un autre côté, nous n'avons pas recommandé les nouvelles versions de TS aux gens, sauf en tant que bonnes pratiques générales ou pour des solutions de contournement spécifiques.
3. Étant donné que TS est livré dans le cadre de Visual Studio, un produit payant avec des contrats de support, nous devrons peut-être définir une extension spécifique à VS pour toute période de support open source définie. Cela ne devrait cependant pas affecter la communauté open source.

@DanielRosenwasser ça vous dérange de regarder ça quand vous avez le temps ?

2,8 est maintenant le nouveau minimum. 2.0 - 2.7 ne seront plus testés et les balises ts2.0 - ts2.7 ne seront plus mises à jour sur les packages @types/* existants. Les utilisateurs antérieurs à la version 2.8 qui installent @types/*@latest peuvent obtenir des types qui ne fonctionnent pas pour eux.

Je ne vais pas clore ce sujet car il y a des discussions en cours (et c'est d'ailleurs un méta-problème ?).

@sandersn cela signifie-t-il que la vérification qui vérifie généralement qu'une dépendance a une version supérieure ou égale (par exemple, un package arbitraire (2.x avec x> 1 faisant référence à un autre package avec x = 1) est désormais désactivée?

Demander parce que c'est un blocage majeur du déplacement des typages de nœuds vers l'avant.

@SimonSchick non, ce n'est pas désactivé; cela ne s'applique qu'aux en-têtes qui nécessitent >=2.8 .

En d'autres termes, vous ne pouvez pas mettre à jour @types/node pour exiger 3.1 car il existe de nombreux packages qui spécifient 2.8 ou 2.4 - qui est traité comme 2.8. Mais vous pouvez certainement avoir besoin @types/node 2.8 maintenant. Cela signifie que vous pouvez utiliser des types conditionnels et que vous pouvez supposer que la sémantique 2.8+ s'applique là où elle diffère des anciennes versions.

En fait, la valeur par défaut est 2.8, donc ne pas avoir de version requise dans l'en-tête équivaut à exiger 2.8.

@sandersn , pourrions-nous parler d'une nouvelle mise à jour de la version minimale ? Je pense que c'est le bon moment car la 3.8 est sortie.

Nous en avons discuté en interne et nous penchons vers la prise en charge du calendrier de 30 mois de style nœud. Mais je dois me coordonner avec l'équipe d'intégration de Typescript-VS, qui souhaite avoir un calendrier de support pour le nouveau-TS-dans-l'ancien-VS, donc je n'ai pas encore essayé de relancer la discussion ; si nous nous retrouvons avec 30 mois, la prochaine dépréciation aura lieu en août, nous avons donc un peu de temps.

Mise à jour : J'ai parlé à l'équipe Typescript-Javascript sur VS et ils ont décidé d'un calendrier de 2 ans ou de 2,5 ans. Ils vont rassembler des données d'utilisation pour les aider à choisir entre les deux. J'ai également récupéré leur scénario - c'est le support de l'ancien-TS-dans-le-nouveau-VS.

Sur la base de nos données d'utilisation collectées précédemment [1], je préfère une fenêtre de 2 ans simplement pour réduire le fardeau de la maintenance. Il permet également aux packages importants de commencer à utiliser de nouvelles fonctionnalités 6 mois plus tôt sans effort pour mettre à jour les personnes à charge. Une fenêtre de support courte n'a pas d'inconvénients pratiques que j'ai vus jusqu'à présent.

Cependant, le calendrier du nœud peut amener les gens à s'attendre à une fenêtre de 2,5 ans à la place. Y a-t-il d'autres avantages de la fenêtre plus longue ? Inconvénients qui me manquent?

[1]
Données réimprimées d'en haut :

• La télémétrie indique que 99,9 % des utilisateurs de VS Code sont 3.0 ou plus récents
• La télémétrie indique que 97 % des utilisateurs de VS utilisent la version 3.0 ou une version plus récente
• 20% des packages DT ont déjà opté pour la version 2.8 ou plus récente

Je préfère une fenêtre plus courte; à la fois pour des raisons de réduction de la charge de maintenance et compte tenu des données que vous avez découvertes @sandersn.

Merci pour la mise à jour!

Aussi pour une fenêtre plus courte.

Une longue fenêtre ne profiterait qu'à ceux qui ne mettraient à jour qu'une partie de leurs dépendances, mais jamais de tapuscrit, et cela ne devrait être qu'un très petit groupe.
La plupart du temps, les gens mettent régulièrement à jour toutes leurs dépendances (y compris le tapuscrit), ou pas du tout.
Ou l'inverse : la plupart des développeurs qui n'ont pas pris la peine de mettre à jour leur TypeScript depuis deux ans ne se soucient probablement pas du tout des nouveaux packages et des nouvelles définitions de type.
Donc, cela blesserait probablement beaucoup moins de personnes que vous ne le pensez - et cela empêcherait l'ensemble de l'écosystème d'évoluer.

TL ; DR ; @sandersn , que pensez-vous de 18 mois ?

Mes pensées :

J'ai écrit

L'option 2 Node.js a une politique de 12 + 18 mois avant la fin de vie. Nous pouvons utiliser la même approche, 2,5 ans. Cela peut être trop long, mais pas moins de 2 ans.

mais je ne me souviens pas pourquoi j'ai pensé que 2 ans était la bonne période. Je ne peux pas justifier logiquement ces 2 ans. Maintenant, avec un esprit neuf, il me semble qu'il aurait dû y avoir ..., but not less 18 months .

Chaque version majeure couverte par le plan LTS sera activement maintenue pendant une période de 12 mois à compter de la date à laquelle elle entrera dans la couverture LTS. Après ces 12 mois de support actif, la version majeure passera en mode "maintenance" pendant 18 mois supplémentaires. Avant Node.js 12, la période active était de 18 mois et la période de maintenance de 12 mois. (c) Plan de publication de Node.js

Motivation : chaque version de TypeScipt est d'abord publiée en tant que rc/beta. Ainsi, chaque version stable a un mode de maintenance dès le premier jour et 18 mois suffisent.

C'est logique. Mais si nous utilisons 18 mois comme fenêtre, nous obsolèterons 3.1 en mars 2020. Étant donné que notre télémétrie a montré un nombre important d'utilisateurs VS toujours sur 3.1, je ne pense pas que 3.1 devrait encore être obsolète.

Cependant, il est possible que ces chiffres aient changé depuis la fin octobre. Je vais découvrir ce qu'ils sont actuellement.

Les nombres d'utilisation pour 3.1 n'ont pas beaucoup diminué dans VS depuis fin octobre. Fait intéressant, 95% de l'utilisation est concentrée dans 3.9 - 3.4.

Je pense que 3.1 est toujours tellement utilisé parce que VS vous évitera de mettre à jour le texte dactylographié lors du téléchargement des mises à jour, mais je n'en suis pas sûr. Quoi qu'il en soit, ce comportement est susceptible de se poursuivre dans les futures versions de VS, ainsi que d'autres IDE qui ne sont pas mis à jour aussi souvent.

En résumé, pour prendre en charge 98 % des utilisateurs de VS, nous avons besoin d'une fenêtre de 2 ans. Pour prendre en charge 95 %, nous n'avons besoin que d'une fenêtre d'un an ! Mais il ne sert à rien d'avoir quoi que ce soit entre les deux.

Je soutiens toujours 2 ans sur la base de ces données.

Il me semble que la discussion ici s'est terminée. Je vais opter pour une fenêtre de support de 2 ans.

2.8 publié le 27 mars 2018 , je ne vais donc pas supprimer le support immédiatement. Mais je le ferai dans les prochaines semaines, et je mettrai à jour et fermerai ce problème quand ce sera fait.

J'ai un PR qui ajoute de la documentation au README au #42834.

J'ai traduit les modifications de la documentation en russe au n° 42881

Quelqu'un pourrait-il aider avec les changements de traduction en :

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

@kingwl @armanio123 @saschanaz sont les dactylographes les plus impliqués que je connaisse qui sont des locuteurs natifs pour ces trois langues.

(Bien sûr, n'hésitez pas à l'ignorer si vous êtes trop occupé.)

La tâche ajoute-t-elle la traduction des modifications dans #42834 ?

J'ai traduit les modifications de la documentation en russe au n° 42818

C'est le #42881 😁

Oui.

La tâche ajoute-t-elle la traduction des modifications dans #42834 ?

J'ai traduit les modifications de la documentation en russe au n° 42818

C'est le #42881 😁

Fixé. Désolé, j'ai fait la faute de frappe.

Mise à jour : en même temps que la version 3.9, je viens de supprimer le support de la version 2.8.

J'ai retardé la dépréciation pour deux raisons.

1 Retard général covid-19.

1. Nous sommes en train de basculer l'infrastructure d'éditeur de types vers un dépôt unique qui publie dans l'espace de noms @definitelytyped/* . La mise à jour de la version fait désormais partie de ce monorepo. Malheureusement, nous attendons toujours que le bureau MS open source rende le monorepo open source, mais cela ne devrait pas tarder.

Même si la version 4.0 ne sera pas en mai, je supprimerai toujours la prise en charge de la 2.9 en mai comme prévu. Cela devrait être un peu plus facile avec la nouvelle configuration.