Definitelytyped: META - Memperbarui versi TypeScript minimum

Kapan unknown ditambahkan? Pergi besar atau pulang! Semua any di DT sejauh ini merupakan sumber terbesar dari bug "typescript seharusnya menangkapnya" di bagian ini.

Kapan unknown ditambahkan?

3.0

Anda. Jadi, 99,9%!

Saya setuju kita harus melakukan ini. Mari kita lakukan!

Tolong, bisakah Anda meningkatkannya perlahan seiring waktu? 2.1 satu bulan, 2.2 berikutnya, dan seterusnya?

Setiap versi memiliki beberapa perubahan kecil. Akan lebih mudah untuk memahami masalah apa yang ditimbulkannya dengan berjalan perlahan dan metodis pada awalnya.

Proyek dalam mode pemeliharaan sering kali tidak memiliki bandwidth untuk mengatasi perubahan yang mengganggu tersebut, terutama jika itu adalah inti dari infrastruktur.

Ya tolong, pengetikan node khususnya telah mengalami kekurangan fitur yang lebih baru dan banyak ~hacks~ solusi yang harus digunakan.

Proyek @JoshuaKGoldberg dalam mode pemeliharaan kemungkinan tidak akan meningkatkan versi definisi tipe bulan demi bulan, ya?

@JoshuaKGoldberg ingat bahwa memutakhirkan DT tidak menghapus definisi tipe historis yang telah diterbitkan ke npm. @types versi bersejarah hidup selamanya seperti Mumm-Ra.

Anda akan dapat bergantung pada mereka terlepas dari mana DT pergi versi-bijaksana.

Masuk akal

Hai @RyanCavanaugh ,
Saya mendukung ide seperti itu 100%. TypeScript v2.0 adalah pemblokir untuk sistem tipe yang lebih baik untuk banyak paket termasuk node .
Saya peduli tentang Transparansi dan prediktabilitas untuk komunitas dan bisnis . Ada pertanyaan:

• Menurut Anda kapan waktu yang tepat untuk mengubah versi TypeScript yang didukung minimum? Selama rilis TS 3.7?
• Perbaiki saya jika saya salah, tetapi ini terlihat seperti akhir masa pakai untuk versi TypeScript sebelum 2.8?
• Bisakah kita memiliki jadwal yang mirip dengan Node.js ? Dokumen tersebut akan membantu tim pengembang mendorong bisnis untuk menyetujui sumber daya pengembangan untuk pembaruan.

Adakah alasan mengapa ini 2.8 dan bukan versi yang berbeda? (Misalnya 3.0 untuk unknown .)

2.8 adalah ketika tipe bersyarat diperkenalkan

Sangat mendukung.

Tolong, saat Anda melakukannya, pertimbangkan untuk mengatur jadwal (semi-)formal sehingga komunitas dapat mengandalkan versi minimum yang dapat diprediksi meningkat seiring waktu. Sesuatu seperti: "Setiap tahun di bulan November, kami berencana memperbarui versi TypeScript minimum ke rilis dari 18 bulan sebelumnya. Harap rencanakan dengan tepat."

@donaldpipowitch
Dari pengguna pra-3.0, kami melihat sekelompok orang masih menggunakan 2.8. (Dan, tentu saja, tipe bersyarat menjadikan 2.8 sebagai target populer untuk tipe DT seperti yang ditunjukkan oleh @IllusionMH .)

Kami berharap untuk meninjau kembali masalah ini secara berkala karena kami berharap orang-orang terus meningkatkan.

@galkin
Secara teknis, TypeScript versi lama tidak diservis sama sekali, dan perubahan ini merupakan penghentian layanan dari Pasti Diketik. Dan tentu saja TypeScript versi lama dapat terus mendapatkan versi paket DT yang ada. Mereka tidak akan mendapatkan pembaruan.

Namun, itu hanya teknis. Ini akan menjadi ide yang baik bagi kita untuk membuat jadwal seperti LTS. Kami belum memulai hal seperti itu. Dalam hal ini datanya cukup jelas untuk membuat keputusan post-hoc menjadi mudah. Saya belum yakin bagaimana memprediksi tanggal yang baik untuk penghentian di masa mendatang.

Re: tanggal: Saya harus memperbarui infrastruktur DT untuk 3.7, jadi itu akan terjadi pada hari rilis 3.7 sebagai bagian dari rilis.

Ini akan menjadi ide yang baik bagi kita untuk membuat jadwal seperti LTS.

Hanya ingin mengulangi Saya pikir jadwal semacam ini adalah ide yang sangat solid.

@johnnyreilly kami sedang mencari di sekitar Microsoft untuk preseden. Tidak ada yang seperti Pasti Diketik!

@RyanCavanaugh , ada pembaruan?

@galkin jika Anda memiliki jadwal penghentian yang diusulkan, harap kirimkan ke utas ini sehingga kami dapat berdiskusi.

@sandersn , inilah pemikiran saya tentang masalah ini

• Apakah kita memerlukan End-of-life (EOL) untuk Versi TypeScript?
  Tentu saja ya. Mendukung setiap versi TypeScript yang dibuat membutuhkan sumber daya berlebih.
• Mengapa kita harus memiliki jadwal EOL?
  _Praktik terbaik adalah bersikap terbuka dan jelas dengan keadaan proyek Anda. Jika Anda tidak lagi mendukung sebuah proyek, atau Anda sedang dalam proses menghentikannya, buatlah itu menjadi jelas bagi siapa saja yang akan menemukan kode Anda_ (c) Jared Smith.
• Apa yang harus digunakan sebagai dasar untuk jadwal?
  Analisis? Setiap keputusan berdasarkan analitik adalah kompromi. Setiap keputusan tersebut merupakan jawaban atas pertanyaan bagian komunitas/bisnis mana yang akan kita jajaki. WordPress memiliki masalah serupa apa versi minimal WP/PHP/MySQL yang harus mereka dukung. Ini cara yang berbahaya.
  Jadwal alat yang bergantung? Kode Visual/Microsoft Azure/Angular/dll. Terlalu banyak pilihan dan terlalu mudah memulai perang suci baru.
  Proses TC39? Pilihan bagus, tetapi TC39 tidak dan tidak akan memperkenalkan EoL untuk fitur bahasa apa pun.
  Node.js? Node.js adalah driver untuk komunitas JS dengan jadwal rilis/EOL. TypeScript menggunakan Node.js. Saya melihat ini sebagai dasar terbaik untuk jadwal.
• Bagaimana cara membuat jadwalnya?
  Opsi 1. Kaitkan versi TypeScript dengan versi Node.js dan umumkan EOL serupa. Misalnya 2 tahun yang lalu Node.js v8 memulai LTS dan TypeScript v2.6 dirilis , jadi 2019.12.31 adalah EOL.
  Opsi 2 Node.js memiliki kebijakan 12 + 18 bulan sebelum EOL. Kita bisa menggunakan pendekatan yang sama, 2,5 tahun. Ini bisa terlalu lama, tetapi tidak kurang dari 2 tahun.
  Opsi 3 Lakukan pertemuan dengan pengambil keputusan dan bagikan dengan hasil komunitas sebagaimana adanya

Jadi proposal saya terlihat seperti itu:

versi | Dirilis | Akhir Kehidupan dalam 2,5 tahun | Akhir Hidup dalam 2 tahun
-- | -- | -- | --
2.1 | Desember 2016 | Juni 2019 | Desember 2018
2.2 | Februari 2017 | Agustus 2019 | Februari 2019
2.3 | April 2017 | September 2019 | April 2019
2.4 | Juni 2017 | November 2019 | Juni 2019
2.5 | Agustus 2017 | Januari 2020 | Agustus 2019
2.6 | Oktober 2017 | Maret 2020 | Oktober 2019
2.7 | Januari 2018 | Juli 2020 | Januari 2020
2.8 | Maret 2018 | Agustus 2020 | Februari 2020
2.9 | Mei 2018 | Oktober 2020 | April 2020
3 | Juli 2018 | Desember 2020 | Juni 2020
3.1 | September 2018 | Maret 2021 | Agustus 2020
3.2 | November 2018 | Mei 2021 | Oktober 2020
3.3 | Januari 2019 | Juli 2021 | Desember 2020
3.4 | Maret 2019 | Agustus 2021 | Februari 2021
3.5 | Mei 2019 | Oktober 2021 | April 2021
3.6 | Agustus 2019 | Januari 2022 | Juli 2021
3.7 | November 2019 | Mei 2022 | Oktober 2021

Wow, ini luar biasa! Terima kasih atas pemikiran yang Anda masukkan ke dalam ini.

Beberapa poin kecil:

1. Pasti Diketik dan TypeScript adalah proyek yang berbeda, meskipun mereka harus memiliki jadwal EOL yang sama.
2. Apa arti EOL untuk DT dijelaskan di atas, tetapi tidak begitu jelas untuk TS. Kami tidak pernah membuat versi patch lebih dari satu versi minor sepengetahuan saya. Di sisi lain, kami tidak merekomendasikan versi TS yang lebih baru kepada orang-orang kecuali sebagai praktik umum yang baik, atau untuk solusi khusus.
3. Karena TS dikirimkan sebagai bagian dari Visual Studio, produk berbayar dengan kontrak dukungan, kami mungkin harus menentukan ekstensi khusus VS untuk periode dukungan sumber terbuka apa pun yang ditentukan. Ini seharusnya tidak mempengaruhi komunitas open source.

@DanielRosenwasser apakah Anda keberatan melihat ini ketika Anda punya waktu?

2.8 sekarang adalah minimum baru. 2.0 - 2.7 tidak akan diuji lagi dan tag ts2.0 - ts2.7 tidak akan lagi diperbarui pada paket @types/* yang ada. Pengguna pra-2.8 yang memasang @types/*@latest mungkin mendapatkan jenis yang tidak berfungsi untuk mereka.

Saya tidak akan menutup masalah ini karena ada diskusi yang sedang berlangsung (dan itu adalah masalah meta selain?).

@sandersn apakah itu berarti bahwa pemeriksaan yang biasanya memverifikasi bahwa ketergantungan memiliki versi yang lebih besar atau sama (mis. paket arbitrer (2.x dengan x > 1 merujuk paket lain dengan x = 1) sekarang dinonaktifkan?

Bertanya karena itu adalah pemblokiran utama untuk memindahkan pengetikan simpul ke depan.

@SimonSchick tidak, itu tidak dinonaktifkan; itu hanya berlaku untuk header yang membutuhkan >=2.8 .

Dengan kata lain, Anda tidak dapat memperbarui @types/node untuk memerlukan 3.1 karena ada banyak paket yang menetapkan 2.8 atau 2.4 -- yang diperlakukan sebagai 2.8. Tapi Anda pasti dapat memiliki @types/node membutuhkan 2.8 sekarang. Itu berarti Anda dapat menggunakan tipe kondisional, dan Anda dapat mengasumsikan bahwa 2.8+ semantik berlaku di mana mereka berbeda dari versi lama.

Faktanya, defaultnya adalah 2.8, jadi tidak memiliki versi yang diperlukan di header sama sekali sama dengan membutuhkan 2.8.

@sandersn , bisakah kita membicarakan pembaruan baru dari versi minimal? Saya pikir ini saat yang tepat karena 3.8 dirilis.

Kami telah mendiskusikannya secara internal dan condong ke arah mendukung jadwal 30 bulan bergaya simpul. Tapi saya perlu berkoordinasi dengan tim integrasi Typescript-VS, yang ingin memiliki timeline dukungan untuk new-TS-in-old-VS, jadi saya belum mencoba memulai kembali diskusi; jika kita berakhir dengan 30-bulan, penghentian berikutnya adalah pada bulan Agustus, jadi kita punya sedikit waktu.

Pembaruan: Saya berbicara dengan tim TypeScript-Javascript di VS dan mereka telah memutuskan jadwal 2 tahun atau 2,5 tahun. Mereka akan mengumpulkan beberapa data penggunaan untuk membantu mereka memutuskan di antara keduanya. Saya juga mendapatkan skenario mereka mundur -- ini dukungan untuk lama-TS-in-baru-VS.

Berdasarkan data penggunaan kami yang dikumpulkan sebelumnya [1], saya lebih memilih jangka waktu 2 tahun hanya untuk mengurangi beban pemeliharaan. Ini juga memungkinkan paket penting mulai menggunakan fitur baru 6 bulan lebih cepat tanpa upaya untuk memperbarui tanggungan. Jendela dukungan singkat tidak memiliki kelemahan praktis yang telah saya lihat sejauh ini.

Namun, jadwal node dapat menyebabkan orang mengharapkan jendela 2,5 tahun sebagai gantinya. Apakah ada keuntungan lain dari jendela yang lebih panjang? Kekurangan yang saya lewatkan?

[1]
Data dicetak ulang dari atas:

• Telemetri menunjukkan 99,9% pengguna VS Code adalah 3.0 atau lebih baru
• Telemetri menunjukkan 97% pengguna VS menggunakan 3.0 atau lebih baru
• 20% paket DT telah memilih 2.8 atau yang lebih baru

Saya menyukai jendela yang lebih pendek; baik untuk alasan mengurangi beban pemeliharaan dan mengingat data yang Anda temukan @sandersn.

Terima kasih atas pembaruannya!

Juga untuk jendela yang lebih pendek.

Jendela panjang hanya akan menguntungkan mereka yang hanya akan memperbarui sebagian dari dependensinya, tetapi tidak pernah TypeScript, dan itu seharusnya hanya grup yang sangat kecil.
Sebagian besar waktu, orang secara teratur memperbarui semua dependensi mereka (termasuk TypeScript), atau tidak sama sekali.
Atau sebaliknya: Sebagian besar pengembang yang tidak repot-repot memperbarui TypeScript mereka dalam dua tahun mungkin tidak peduli dengan paket baru & definisi tipe baru sama sekali.
Jadi ini mungkin akan merugikan lebih sedikit orang daripada yang mungkin Anda duga - dan ini membuat seluruh ekosistem tidak berkembang.

TL; DR; @sandersn , apa pendapat Anda tentang 18 bulan?

pikiran saya :

saya menulis

Opsi 2 Node.js memiliki kebijakan 12 + 18 bulan sebelum EOL. Kita bisa menggunakan pendekatan yang sama, 2,5 tahun. Ini bisa terlalu lama, tetapi tidak kurang dari 2 tahun.

tapi saya tidak ingat mengapa saya pikir 2 tahun adalah periode waktu yang tepat. Saya tidak bisa secara logis membuktikan 2 tahun ini. Sekarang, dengan pikiran yang segar, menurut saya seharusnya ada ..., but not less 18 months .

Setiap versi utama yang dicakup oleh paket LTS akan dipertahankan secara aktif untuk jangka waktu 12 bulan sejak tanggal masuk cakupan LTS. Setelah 12 bulan dukungan aktif tersebut, versi utama akan beralih ke mode "pemeliharaan" selama 18 bulan tambahan. Sebelum Node.js 12 masa aktif adalah 18 bulan dan masa pemeliharaan 12 bulan. (c) Rencana Rilis Node.js

Motivasi : setiap versi TypeScipt dirilis sebagai rc/beta terlebih dahulu. Jadi setiap rilis stabil memiliki mode pemeliharaan dari hari pertama dan 18 bulan sudah cukup baik.

Itu logis. Tetapi jika kami menggunakan 18 bulan sebagai jendela, kami akan menghentikan 3.1 pada Maret 2020. Mengingat telemetri kami menunjukkan sejumlah besar pengguna VS masih menggunakan 3.1, saya rasa 3.1 belum seharusnya dihentikan.

Namun, kemungkinan angka tersebut akan berubah sejak akhir Oktober. Aku akan mencari tahu seperti apa mereka saat ini.

Angka penggunaan untuk 3.1 belum turun sebanyak itu di VS sejak akhir Oktober. Menariknya, 95% penggunaan terkonsentrasi di 3,9 - 3,4.

Saya pikir 3.1 masih banyak digunakan karena VS akan memungkinkan Anda menghindari pembaruan TypeScript saat mengunduh pembaruan, tetapi saya tidak yakin. Terlepas dari itu, perilaku ini kemungkinan akan berlanjut di versi VS yang akan datang, ditambah IDE lain yang tidak sering diperbarui.

Singkatnya, untuk mendukung 98% pengguna VS, kami membutuhkan waktu 2 tahun. Untuk mendukung 95%, kami hanya membutuhkan jendela 1 tahun! Tapi tidak ada gunanya memiliki sesuatu di antaranya.

Saya masih mendukung 2 tahun berdasarkan data itu.

Sepertinya diskusi di sini telah berakhir. Aku akan pergi dengan jendela dukungan 2 tahun.

2.8 dirilis pada 27 Maret 2018 , jadi saya tidak akan segera menghapus dukungan. Tapi saya akan melakukannya dalam beberapa minggu ke depan, dan saya akan memperbarui dan menutup masalah ini setelah selesai.

Saya memiliki PR yang menambahkan dokumentasi ke README di #42834.

Saya menerjemahkan perubahan dokumentasi ke dalam bahasa Rusia di #42881

Bisakah seseorang membantu dengan perubahan terjemahan menjadi:

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

@kingwl @armanio123 @saschanaz adalah TypeScripters yang paling terlibat yang saya tahu yang merupakan penutur asli untuk ketiga bahasa tersebut.

(Tentu saja jangan ragu untuk mengabaikan ini jika Anda terlalu sibuk.)

Apakah tugas menambahkan terjemahan untuk perubahan #42834?

Saya menerjemahkan perubahan dokumentasi ke dalam bahasa Rusia di #42818

Ini #42881 😁

Ya.

Apakah tugas menambahkan terjemahan untuk perubahan #42834?

Saya menerjemahkan perubahan dokumentasi ke dalam bahasa Rusia di #42818

Ini #42881 😁

Tetap. Maaf, saya membuat kesalahan ketik.

Pembaruan: Pada saat yang sama dengan rilis 3.9, saya baru saja menghapus dukungan untuk 2.8.

Saya menunda penghentian karena dua alasan.

1 Keterlambatan covid-19 umum.

1. Kami sedang mengalihkan infrastruktur penerbit tipe ke monorepo yang memublikasikan ke namespace @definitelytyped/* . Pembaruan versi sekarang menjadi bagian dari monorepo itu. Sayangnya kami masih menunggu di MS open source office untuk membuat monorepo open source, tetapi harus segera.

Meskipun rilis 4.0 tidak akan dilakukan pada bulan Mei, saya tetap akan menghapus dukungan untuk 2.9 pada bulan Mei seperti yang direncanakan. Seharusnya sedikit lebih mudah dengan pengaturan baru.