Closed kou029w closed 3 years ago
それ (メンテナーによる setup.sh 実行時点でのアクティブLTSのリポジトリが導入される) であれば明示的に 14.x としたほうが setup.sh を流して試行する際に、バージョンが明確で意図的にバージョンが上げれてよいかと思います
https://deb.nodesource.com/setup_14.x などではなく https://deb.nodesource.com/setup_lts.x と指定することはメンテナンスの単純さの点で優位と私は考えます。これに関してはいかがですか。 > @WhiteHawk-taka
またメジャーバージョンを柔軟に変更したいというユースケースについては、バージョンの差異に起因する不都合とのトレードオフがあると私は考えており、少なくともメンテナー以外のエンドユーザーのnode srv.js
のプロセスについてはバージョンを変更させない状態で提供するのが望ましいと考えます。
バージョンの差異に起因する不都合の解決策として、私の提案としては下記の2点のいずれかです。
これらに関してはいかがですか。 > @WhiteHawk-taka
起票ありがとうございます。
https://deb.nodesource.com/setup_14.x などではなく https://deb.nodesource.com/setup_lts.x と指定することはメンテナンスの単純さの点で優位と私は考えます。これに関してはいかがですか。
おっしゃるとおり setup.sh
のメンテナンスの点では優位かと思います。
ただし、そのイメージが作成されたときの node のバージョンがコード上でパッと見たときに不明になる点・将来的に LTS が 16系になったときコミュニティ的に即時に setup.sh
の検証ができない点を考慮すると 14.x
としたほうが良さそうに思います。
またメジャーバージョンを柔軟に変更したいというユースケースについては、バージョンの差異に起因する不都合とのトレードオフがあると私は考えており、少なくともメンテナー以外のエンドユーザーのnode srv.jsのプロセスについてはバージョンを変更させない状態で提供するのが望ましいと考えます。
はい、この点について基本的には私も同意です。
しかし、バージョンを変更したいユーザーもいるかと思いますので、変更の方法を予め提示できたほうがエンドユーザーが意図的にバージョンを変更した際に戻すことが楽という利点があるかと思います。
ご提案いただいた方法の中では私は 1 のほうがよいかと思います。
ご回答ありがとうございます。
たしかにコミニュティ内での混乱を避ける目的で https://deb.nodesource.com/setup_14.x 等メジャーバージョンを明示したほうが良さそうですね。そうしましょう。
システム内のNode.jsのバージョンの固定については apt-mark hold
を使用しましょう。
バージョンの変更手段については確かに従来nを使用している利用者もいる気がするのでシステム内にインストールし提供したほうが良さそうですね。そうしましょう。
Node.js専用のバージョン管理ツールの導入の是非
背景としては下記:
https://github.com/chirimen-oh/chirimen/issues/109#issuecomment-893166495 より:
https://github.com/chirimen-oh/chirimen/pull/111#discussion_r684139354 より: