Definitelytyped: META - تحديث الحد الأدنى من إصدار TypeScript

متى تمت إضافة unknown ؟ اذهب كبيرا او اذهب الى المنزل! كل any في DT هو إلى حد بعيد أكبر مصدر لأخطاء "الكتابة يجب أن تمسكها" في هذه الأجزاء هنا.

متى تمت إضافة unknown ؟

3.0

أنت. لذا ، 99.9٪!

أوافق على أننا يجب أن نفعل هذا. هيا بنا نقوم بذلك!

من فضلك ، هل يمكنك بدلاً من ذلك زيادتها ببطء بمرور الوقت؟ 2.1 شهر واحد ، 2.2 في الشهر التالي ، وهكذا؟

كل نسخة لديها بعض التغييرات الصغيرة. سيكون من الأسهل فهم المشكلات التي يسببها هذا من خلال العمل ببطء ومنهجية في البداية.

غالبًا ما لا تمتلك المشاريع في وضع الصيانة النطاق الترددي للتغلب على تلك التغييرات العاجلة ، خاصةً إذا كانت أساسية للبنية التحتية.

نعم من فضلك ، لقد عانت كتابات node على وجه الخصوص من نقص الميزات الأحدث وكان لابد من استخدام العديد من الحلول البديلة.

JoshuaKGoldberg من غير المحتمل أن تقوم مشاريع JoshuaKGoldberg في وضع الصيانة بترقية إصدارات تعريفات النوع شهرًا بعد شهر ، أليس كذلك؟

تذكر JoshuaKGoldberg أن ترقية DT لا تزيل تعريفات النوع التاريخية التي تم نشرها بالفعل إلى npm. الإصدارات التاريخية @types تعيش إلى الأبد مثل Mumm-Ra.

ستكون قادرًا على الاعتماد على هؤلاء بغض النظر عن المكان الذي ينتقل إليه DT من حيث الإصدار.

من المنطقي

مرحبًا RyanCavanaugh ،
أنا أؤيد هذه الفكرة 100٪. TypeScript v2.0 هو مانع لنظام كتابة أفضل للعديد من الحزم بما في ذلك node .
أنا مهتم بالشفافية والقدرة على التنبؤ للمجتمع والأعمال . هناك أسئلة:

• متى تعتقد أن الوقت المناسب هو تغيير الحد الأدنى من إصدار TypeScript المدعوم؟ أثناء الإصدار TS 3.7؟
• صححني إذا كنت مخطئًا ، لكن هذا يبدو وكأنه نهاية العمر لإصدارات TypeScript قبل الإصدار 2.8؟
• هل يمكن أن يكون لدينا جدول زمني مشابه لـ Node.js ؟ سيساعد هذا المستند فرق التطوير على دفع الأعمال للموافقة على موارد التطوير للتحديث.

أي سبب لماذا هو 2.8 وليس إصدارًا مختلفًا؟ (على سبيل المثال ، 3.0 مقابل unknown .)

2.8 عندما تم تقديم الأنواع الشرطية

بشكل كبير لصالح.

من فضلك ، أثناء تواجدك فيه ، ضع في اعتبارك إعداد جدول (شبه) رسمي حتى يتمكن المجتمع من الاعتماد على الحد الأدنى من الإصدار الذي يتزايد بشكل متوقع بمرور الوقت. شيء من هذا القبيل: "كل عام في تشرين الثاني (نوفمبر) ، نخطط لتحديث الحد الأدنى من النسخة المطبوعة إلى الإصدار قبل 18 شهرًا. يُرجى التخطيط وفقًا لذلك."

تضمين التغريدة
من بين مستخدمي ما قبل 3.0 ، رأينا مجموعة من الأشخاص لا يزالون على 2.8. (وبالطبع ، تجعل الأنواع الشرطية 2.8 هدفًا شائعًا لأنواع DT كما يشير IllusionMH .)

نتوقع إعادة النظر في هذه المشكلة بشكل دوري لأننا نأمل أن يستمر الأشخاص في الترقية.

تضمين التغريدة
من الناحية الفنية ، لا تتم صيانة الإصدارات القديمة من Typescript على الإطلاق ، وهذا التغيير هو إيقاف الخدمة من Definitely Typed. وبالطبع يمكن للإصدارات القديمة من Typescript الاستمرار في الحصول على الإصدارات الحالية من حزم DT. هم فقط لن يحصلوا على التحديثات.

ومع ذلك ، هذا مجرد تقني. سيكون من الجيد بالنسبة لنا إنتاج جدول زمني يشبه LTS. لم نبدأ في أي شيء من هذا القبيل حتى الآن. في هذه الحالة ، كانت البيانات واضحة بما يكفي لجعل القرار اللاحق سهلًا. لست متأكدًا بعد من كيفية التنبؤ بموعد جيد لعمليات الإهمال المستقبلية.

إعادة: التاريخ: يجب أن أقوم بتحديث البنية الأساسية لـ DT لـ 3.7 على أي حال ، لذلك سيحدث في يوم الإصدار 3.7 كجزء من الإصدار.

سيكون من الجيد بالنسبة لنا إنتاج جدول زمني يشبه LTS.

أردت فقط أن أردد أعتقد أن هذا النوع من الجدول الزمني فكرة قوية حقًا.

johnnyreilly نحن نبحث في Microsoft عن سابقة. لا يوجد شيء مثل "مكتوب بالتأكيد" بالرغم من ذلك!

RyanCavanaugh ، أي تحديثات؟

galkin إذا كان لديك جدول زمني مقترح للإيقاف ، فالرجاء إرساله إلى هذا الموضوع حتى نتمكن من مناقشته.

sandersn ، ها هي أفكاري حول هذه المسألة

• هل نحتاج إلى نهاية العمر (EOL) لإصدار TypeScript؟
  بكل تأكيد نعم. يتطلب دعم كل إصدار تم إنشاؤه من TypeScript موارد فائضة.
• لماذا يجب أن يكون لدينا جدول موسوعة الحياة؟
  _أفضل ممارسة هي أن تكون واضحًا وواضحًا بشأن حالة مشروعاتك. إذا لم تعد تدعم مشروعًا ما ، أو كنت بصدد الانتهاء منه ، فاجعل ذلك واضحًا بشكل مؤلم لأي شخص قد يتعثر عبر رمزك_ (ج) جاريد سميث.
• ما الذي يجب استخدامه كأساس للجدول الزمني؟
  تحليلات؟ كل قرار يعتمد على التحليلات هو حل وسط. كل قرار من هذا القبيل هو إجابة على السؤال عن أي جزء من المجتمع / الأعمال سنستفزه. يواجه WordPress مشكلة مماثلة في الحد الأدنى من إصدار WP / PHP / MySQL الذي يجب أن يدعمه. إنها طريقة خطيرة.
  الجدول الزمني للأداة التابعة؟ الكود المرئي / Microsoft Azure / الزاوي / إلخ. خيارات كثيرة جدًا ومن السهل جدًا بدء حرب مقدسة جديدة.
  عملية TC39؟ خيار جيد ، لكن TC39 لا ولن يقدم EoL لأي ميزة لغوية.
  Node.js؟ Node.js هو سائق لمجتمع JS مع جدول إصدار / موسوعة الحياة. يستخدم TypeScript Node.js. أرى أن هذا هو أفضل قاعدة للجدول الزمني.
• كيف يتم إنشاء الجدول؟
  الخيار 1. إقران إصدار TypeScript بإصدار Node.js والإعلان عن EOL مماثلة. على سبيل المثال ، منذ عامين ، بدأ Node.js v8 تشغيل LTS وتم إصدار TypeScript v2.6 ، لذلك 2019.12.31 هو EOL.
  الخيار 2 لدى Node.js سياسة 12 + 18 شهرًا قبل EOL. يمكننا استخدام نفس النهج ، 2.5 سنة. يمكن أن تكون طويلة جدًا ، ولكن ليس أقل من عامين.
  الخيار 3 عقد لقاء مع صانعي القرار ومشاركتها مع المجتمع نتيجة كما كانت

لذا يبدو اقتراحي على هذا النحو:

الإصدار | صدر | نهاية الحياة بعد 2.5 سنة | نهاية الحياة بعد سنتين
- | - | - | -
2.1 | ديسمبر 2016 | يونيو 2019 | ديسمبر 2018
2.2 | فبراير 2017 | أغسطس 2019 | فبراير 2019
2.3 | أبريل 2017 | سبتمبر 2019 | أبريل 2019
2.4 | يونيو 2017 | نوفمبر 2019 | يونيو 2019
2.5 | أغسطس 2017 | يناير 2020 | أغسطس 2019
2.6 | أكتوبر 2017 | مارس 2020 | أكتوبر 2019
2.7 | يناير 2018 | يوليو 2020 | يناير 2020
2.8 | مارس 2018 | أغسطس 2020 | فبراير 2020
2.9 | مايو 2018 | أكتوبر 2020 | أبريل 2020
3 | يوليو 2018 | ديسمبر 2020 | يونيو 2020
3.1 | سبتمبر 2018 | مارس 2021 | أغسطس 2020
3.2 | نوفمبر 2018 | مايو 2021 | أكتوبر 2020
3.3 | يناير 2019 | يوليو 2021 | ديسمبر 2020
3.4 | مارس 2019 | أغسطس 2021 | فبراير 2021
3.5 | مايو 2019 | أكتوبر 2021 | أبريل 2021
3.6 | أغسطس 2019 | يناير 2022 | يوليو 2021
3.7 | نوفمبر 2019 | مايو 2022 | أكتوبر 2021

نجاح باهر هذا أمر عجيب! شكرا على الفكر الذي وضعته في هذا.

زوجان من النقاط الصغيرة:

1. تعد "الكتابة المؤكدة" و "Typescript" مشروعين مختلفين ، على الرغم من أنه يجب أن يكون لهما نفس الجدول الزمني لموسوعة الحياة.
2. ما تعنيه موسوعة الحياة بالنسبة إلى DT مذكور أعلاه ، لكنه ليس واضحًا جدًا بالنسبة لـ TS. لم نقم مطلقًا بإنشاء إصدار تصحيح أكثر من إصدار ثانوي على حد علمي. على الجانب الآخر ، لم نوصي بإصدارات أحدث من TS للأشخاص باستثناء ممارسة جيدة عامة ، أو لحلول محددة.
3. نظرًا لأن TS يشحن كجزء من Visual Studio ، وهو منتج مدفوع مع عقود دعم ، فقد نضطر إلى تحديد امتداد خاص بـ VS لأي فترة دعم مفتوحة المصدر يتم تحديدها. هذا لا ينبغي أن يؤثر على مجتمع المصدر المفتوح بالرغم من ذلك.

DanielRosenwasser هل تمانع في النظر إلى هذا عندما يكون لديك وقت؟

2.8 هو الآن الحد الأدنى الجديد. لن يتم اختبار 2.0 - 2.7 بعد الآن ولن يتم تحديث علامات ts2.0 - ts2.7 على الحزم الحالية @types/* . قد يحصل المستخدمون السابقون لـ 2.8 الذين قاموا بتثبيت @types/*@latest على أنواع لا تناسبهم.

لن أغلق هذه المشكلة نظرًا لوجود مناقشة جارية (وهي مشكلة تعريف بالإضافة إلى ذلك؟).

هل هذا يعني أن التحقق الذي يتحقق عادةً من أن التبعية لها أكبر أو يساوي (على سبيل المثال ، حزمة عشوائية (2.x مع x> 1 تشير إلى حزمة أخرى مع x = 1) تم تعطيلها الآن؟

السؤال لأن هذا يمثل عائقًا رئيسيًا لنقل أنواع العقدة إلى الأمام.

SimonSchick لا ، لم يتم تعطيله ؛ ينطبق فقط على الرؤوس التي تتطلب >=2.8 .

بمعنى آخر ، لا يمكنك تحديث @types/node لتتطلب 3.1 لأن هناك الكثير من الحزم التي تحدد 2.8 أو 2.4 - والتي يتم التعامل معها على أنها 2.8. ولكن يمكنك بالتأكيد الحصول على مبلغ 2.8 @types/node . هذا يعني أنه يمكنك استخدام الأنواع الشرطية ، ويمكنك افتراض تطبيق 2.8+ دلالات حيث تختلف عن الإصدارات القديمة.

في الواقع ، القيمة الافتراضية هي 2.8 ، لذا فإن عدم وجود إصدار مطلوب في الرأس على الإطلاق يعادل طلب 2.8.

sandersn ، هل يمكن أن نتحدث عن التحديث الجديد للإصدار الأدنى؟ أعتقد أنه الوقت المناسب لأن الإصدار 3.8 تم إصداره.

لقد كنا نناقشها داخليًا ونميل نحو دعم جدول 30 شهرًا على غرار العقدة. لكني أحتاج إلى التنسيق مع فريق تكامل Typescript-VS ، الذين يرغبون في الحصول على جدول زمني للدعم لـ new-TS-in-old-VS ، لذلك لم أحاول إعادة بدء المناقشة حتى الآن ؛ إذا انتهى بنا الأمر مع 30 شهرًا ، فسيكون الإيقاف التالي في أغسطس ، لذلك لدينا القليل من الوقت.

تحديث: لقد تحدثت إلى فريق Typescript-Javascript على VS وقرروا إما جدول مدته سنتان أو 2.5 عام. سيقومون بجمع بعض بيانات الاستخدام لمساعدتهم على الاختيار بين الاثنين. لقد حصلت أيضًا على السيناريو الخاص بهم إلى الوراء - إنه دعم لـ TS القديم في الجديد VS.

استنادًا إلى بيانات الاستخدام التي تم جمعها سابقًا [1] ، أفضل نافذة لمدة عامين لتقليل عبء الصيانة. كما أنه يتيح للحزم المهمة البدء في استخدام الميزات الجديدة قبل 6 أشهر دون بذل أي جهد لتحديث المعالين. لا تحتوي نافذة الدعم القصيرة على جوانب سلبية عملية رأيتها حتى الآن.

ومع ذلك ، قد يجعل جدول العقدة الناس يتوقعون نافذة مدتها 2.5 عام بدلاً من ذلك. هل هناك مزايا أخرى للنافذة الأطول؟ مساوئ أني في عداد المفقودين؟

[1]
أعيد طبع البيانات أعلاه:

• يشير القياس عن بعد إلى أن 99.9٪ من مستخدمي VS Code هم 3.0 أو أحدث
• يشير القياس عن بعد إلى أن 97٪ من مستخدمي VS يستخدمون الإصدار 3.0 أو أحدث
• 20٪ من حزم DT اشتركت بالفعل في 2.8 أو أحدث

أفضل نافذة أقصر ؛ لأسباب تتعلق بتقليل عبء الصيانة وبالنظر إلى البيانات التي كشفت عنهاsandersn.

شكرا للتحديث!

أيضا من أجل نافذة أقصر.

ستربح النافذة الطويلة فقط أولئك الذين لن يقوموا إلا بتحديث جزء من تبعياتهم ، ولكن لا يجب أن يكون ذلك مطلقًا ، ويجب أن يكون ذلك مجموعة صغيرة جدًا فقط.
في معظم الأحيان ، يقوم الأشخاص إما بتحديث جميع تبعياتهم (بما في ذلك الكتابة المطبوعة) بانتظام ، أو لا يقوموا بتحديث أي شيء على الإطلاق.
أو العكس: ربما لا يهتم معظم المطورين الذين لم يكلفوا أنفسهم عناء تحديث TypeScript خلال عامين بالحزم الجديدة وتعريفات الأنواع الجديدة على الإطلاق.
لذلك من المحتمل أن يؤذي هذا عددًا أقل بكثير من الأشخاص مما قد تظن - ويمنع النظام البيئي بأكمله من التطور.

TL ؛ DR ؛ sandersn ، ما رأيك في 18 شهرًا؟

افكاري :

كتبت

الخيار 2 لدى Node.js سياسة 12 + 18 شهرًا قبل EOL. يمكننا استخدام نفس النهج ، 2.5 سنة. يمكن أن تكون طويلة جدًا ، ولكن ليس أقل من عامين.

لكن لا أستطيع أن أتذكر لماذا اعتقدت أن سنتين هي الفترة الزمنية المناسبة. لا أستطيع إثبات هذه السنتين منطقيًا. الآن ، بعقل جديد ، يبدو لي أنه كان يجب أن يكون هناك ..., but not less 18 months .

سيتم الاحتفاظ بكل إصدار رئيسي تغطيه خطة LTS بنشاط لمدة 12 شهرًا من تاريخ دخوله في تغطية LTS. بعد 12 شهرًا من الدعم النشط ، سينتقل الإصدار الرئيسي إلى وضع "الصيانة" لمدة 18 شهرًا إضافيًا. قبل Node.js 12 ، كانت الفترة النشطة 18 شهرًا وفترة الصيانة 12 شهرًا. (ج) خطة إصدار Node.js

الحافز : يتم إصدار كل إصدار من TypeScipt كـ rc / beta أولاً. لذلك كل إصدار مستقر له وضع صيانة من اليوم الأول و 18 شهرًا جيدة بما فيه الكفاية.

هذا منطقي. ولكن إذا استخدمنا 18 شهرًا كنافذة ، فسنقوم بإيقاف 3.1 في مارس 2020. نظرًا لأن القياس عن بُعد أظهر عددًا كبيرًا من مستخدمي VS لا يزال على 3.1 ، لا أعتقد أنه يجب إهمال 3.1 بعد.

ومع ذلك ، من المحتمل أن تكون هذه الأرقام قد تغيرت منذ نهاية أكتوبر. سأكتشف ما هم عليه حاليا.

لم تنخفض أرقام الاستخدام لـ 3.1 كثيرًا في VS منذ نهاية أكتوبر. ومن المثير للاهتمام أن 95٪ من الاستخدام يتركز في 3.9 - 3.4.

أعتقد أن الإصدار 3.1 لا يزال مستخدمًا كثيرًا لأن VS سيسمح لك بتجنب تحديث النص المكتوب عند تنزيل التحديثات ، لكنني لست متأكدًا. بغض النظر ، من المحتمل أن يستمر هذا السلوك في الإصدارات المستقبلية من VS ، بالإضافة إلى IDEs الأخرى التي لا يتم تحديثها كثيرًا.

باختصار ، لدعم 98٪ من مستخدمي VS ، نحتاج إلى نافذة لمدة عامين. لدعم 95٪ ، نحتاج فقط إلى نافذة لمدة عام واحد! لكن ليس هناك فائدة كبيرة من وجود أي شيء بينهما.

ما زلت أدعم عامين بناءً على تلك البيانات.

يبدو لي أن المناقشة هنا قد انتهت. سأذهب مع فترة دعم لمدة عامين.

تم إصدار 2.8 في 27 مارس 2018 ، لذلك لن أقوم بإزالة الدعم على الفور. لكنني سأفعل ذلك في الأسبوعين المقبلين ، وسوف أقوم بتحديث وإغلاق هذه المشكلة عند الانتهاء.

لديّ علاقات عامة تضيف وثائق إلى README على الرقم 42834 #.

لقد قمت بترجمة تغييرات الوثائق إلى اللغة الروسية على الرقم 42881

هل يمكن لأي شخص أن يساعد في إجراء تغييرات في الترجمة إلى:

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

kingwl @ armanio123saschanaz هم أكثر من يتكلمون أنواعًا من اللغات الثلاث.

(بالطبع لا تتردد في تجاهل هذا إذا كنت مشغولاً للغاية.)

هل مهمة إضافة الترجمة للتغييرات في # 42834؟

لقد قمت بترجمة تغييرات الوثائق إلى اللغة الروسية على الرقم 42818

إنه # 42881 😁

نعم.

هل مهمة إضافة الترجمة للتغييرات في # 42834؟

لقد قمت بترجمة تغييرات الوثائق إلى اللغة الروسية على الرقم 42818

إنه # 42881 😁

مثبت. آسف ، لقد ارتكبت الخطأ المطبعي.

التحديث: في نفس وقت الإصدار 3.9 ، قمت للتو بإزالة الدعم لـ 2.8.

لقد أخرت الإيقاف لسببين.

1 تأخير عام لفيروس كوفيد -19.

1. نحن في خضم تحويل البنية التحتية لأنواع الناشر إلى monorepo تنشر على مساحة الاسم @definitelytyped/* . تحديث الإصدار هو الآن جزء من هذا monorepo. لسوء الحظ ، ما زلنا ننتظر مكتب MS مفتوح المصدر لجعل monorepo مفتوح المصدر ، ولكن يجب أن يكون قريبًا.

على الرغم من أن الإصدار 4.0 لن يكون في مايو ، إلا أنني سأستمر في إزالة الدعم لـ 2.9 في مايو كما هو مخطط. يجب أن يكون الأمر أسهل قليلاً مع الإعداد الجديد.