コントロールパネルでMisskeyのアップデートを確認できる機能

[syuilo]

Summary

もしくは自動的にお知らせを表示する

Purpose

アップデートが利用可能であることが分かった方が良さそう

Do you want to implement this feature yourself?

• Yes, I will implement this by myself and send a pull request

[samunohito]

👍 とはしたものの、何をもってアップデート可能とするか…

[syuilo]

バージョン比較して新しければ通知する

[sakuhanight]

新しいかの条件文がというのもあるけど、ローカルのバージョンとサーバー側のバージョンが一致しなければ通知でいい気がします

[anatawa12]

sakuhanightさんはクライアントの更新だと思ってそうだけど、syuiloさんは多分サーバー自身の更新を指していそう

[sakuhanight]

🤯

[samunohito]

バージョン比較して新しければ通知する

• package.jsonから自身のバージョンは取れると思いますが、比較先のバージョンは何処から取得するとかの想定はありますか…？？
• 2024.1.0、2024.2.0、2024.12.0だとどれが最新か…とかの比較が難しいかも？
  特に、forkをきって運用しているサーバは独自のサフィックスとバージョン番号を付けているところも多く、想定しない結果になる可能性も無きにしも非ずな気がしており

[samunohito]

じゃあどうしよう、となると難しい話ではありますが…

• バージョンの先頭（[0-9]{4}.[0-9]{1,2}.[0-9]+）は必ずカレンダーバージョニングの数値であると必ず見なす
  （それ以降のサフィックスなどは切り捨てて、年・月・リリース回数をそれぞれ数値にパースして判断）
• 自動バージョンアップ通知そのものを無効化出来るようにする

あたりが現実的なラインでしょうか…

[syuilo]

比較はクライアントでやってるのと同じだわね

[samunohito]

うーーーーむ

比較はクライアントでやってるのと同じだわね

misskey/packages/frontend/src/boot/common.ts

Lines 66 to 80 in 3a42183

	//#region クライアントが更新されたかチェック
	const lastVersion = miLocalStorage.getItem('lastVersion');
	if (lastVersion !== version) {
	miLocalStorage.setItem('lastVersion', version);
	// テーマリビルドするため
	miLocalStorage.removeItem('theme');
	try { // 変なバージョン文字列来るとcompareVersionsでエラーになるため
	if (lastVersion != null && compareVersions(version, lastVersion) === 1) {
	isClientUpdated = true;
	}
	} catch (err) { /* empty */ }
	}
	//#endregion

ここですよね。
lastVersion が自身のサーバのバージョンだとすると…!==で比較しているversionは何処から配信される想定でしょうか？

[syuilo]

GitHubとかで良いんじゃないかしら

[sakuhanight]

Fork運用の場合に欲しいのは本体の更新通知な気がします（Forkメンテナー=運営者のケースが大多数と思われるため）
ところで、これは更新自体も行うことを想定していますか？（それとも「更新あるらしいよ」という通知だけ？）

[samunohito]

GitHubとかで良いんじゃないかしら

となると、配信されるバージョンは2024.12.0のような値になるはずですね。
2024.11.0-ost.0のように、カレンダーバージョンの後に独自のプレフィクスをつけて運用しているforkが数多くあるのですが、
このようなforkは2024.12.0に追従した場合は2024.12.0-ost.0のようになり、単純に!==で比較するだけでは常に更新版がある判定になるのではないか、と懸念しています。

（↑の懸念が1段ぬかしで出てきたのが #15089 (comment) の話）

[syuilo]

この機能はMisskeyを想定しているわね

[syuilo]

更新自体もできたら便利だわね

[syuilo]

この機能はMisskeyを想定しているわね

(この機能に限らずMisskey ProjectではMisskeyしか開発しない)

[syuilo]

WordPressだと自動で更新できたりした気がする

[eternal-flame-AD]

Forkでバージョンは不具合の可能性あるとき (repositoryUrl !== misskey-dev/misskey) ビルド時に最新のコミットタイムスタンプを記録し、それをフロントエンドで最後の公式リリースと比較することは良さそう

[sakuhanight]

hmm...
Forkを考えるときりがなくなるので、基本的にはmisskey-devのみ想定することとしつつ、config等で参照先リポジトリとバージョニングのフォーマットを指定可能だとよいと思います。

[syuilo]

リポジトリはmisskey-dev/misskey以外になることってあるかしら？

[sakuhanight]

リポジトリはmisskey-dev/misskey以外になることってあるかしら？

実際にはFork運用している場合この機能を使用しないかもしれませんが、ハードコードするよりもconfig参照する方が保守性がよいと思います。

[syuilo]

configに書くと、リポジトリ名が変わった時に運営者に変えてもらう必要が生じますね
ハードコードされていればこっちで変えられるからその方が良さそう

[sakuhanight]

それか、constsかなにかに定数として書いておくのはありかもしれません。

[eternal-flame-AD]

misskey-hub にリストされているインスタンスは、自分のインスタンスも含めて、misskey-dev を厳密に追跡しながらも、バージョン管理を別々に行っているインスタンスがあると思います　(公式リリースがまだ出ていないときに 11.0 にアップグレードするなど)。

「前回コミットしてからメジャー アップデートがリリースされました」という通知があれば、役に立つ通知になると思います。

ただし、このようなインスタンスがいくつあるかはよくわかりませんし。。

[sakuhanight]

更新の判定について、GitHubのLatest Release日時とビルド日時を比較するのは良い考えに思います。

[samunohito]

（ちょっと気が早いけど書いておかないと漏れそうなので書いておきます）
ビルド日時やコミット日時のいずれのパターンでも、docker pullでMisskeyを取得・構築した後のバージョンアップ検知が正常に動作するかは要確認です

[sakuhanight]

対応しているデプロイ方式については厳密に定義しておく必要があると思いますね……
(少なくとも、k8sで運用している場合を想定するのは現実的ではないように思えます。)

[syuilo]

普通にバージョンの比較で事足りるんじゃないかしら(実装を複雑にするほどの価値はこの機能にないと思う)

[samunohito]

提案頂いた方針ではなく、シンプルにバージョン比較で…ということなら、独自のバージョンコードを持つサーバに対するフォローはどうしようということになりますね（#15089 (comment) ←この話になる）

[syuilo]

独自のバージョンコードを持つ実装=Misskey派生ソフトという認識だけど、そうとも限らないのかしら

[eternal-flame-AD]

フォークの場合、この機能は更新の実際のリクエストというよりは、最新情報を知らせる礼儀的な通知だけであると考えています。リリース後にコミットした場合、この更新を見たことが無いはずがないと判断するのに十分な情報がないと思います。実際に単に方法論を提案しているだけで、これが実装すべきだと言っているのではありません。

[sakuhanight]

独自のバージョンコードを持つ＝Forkについてですが、その場合はまずForkリポジトリがmisskey-devに追従し、その後にForkリポジトリをデプロイすることになる（２段階）必要なため、この場合の更新元はForkリポジトリになるはずです。
厳密にmisskey-devで運用している場合のみ自動更新を制御可能だと思います。
その場合においても、事故を防止することを目的として十分に検証を行うことは必要だと思います。

[samunohito]

独自のバージョンコードを持つ実装=Misskey派生ソフトという認識
この機能はMisskeyを想定しているわね
(この機能に限らずMisskey ProjectではMisskeyしか開発しない)

ああ、そういう意味か…（そして自分への返信だったのか…）
自分はfork含めてMisskeyであるという定義だったため、そこにすれ違いがありましたね。

つまり、派生ソフト側は考慮しない…ということになりますかね？

[syuilo]

うむむ、話が脱線してきている気がする
MisskeyはMisskeyの開発しか行わず、Misskey派生ソフト用の機能は実装しない
このIssueについても、「MisskeyサーバーにMisskeyの更新を通知する機能」を意図していて、「Misskey以外のソフトウェアを利用しているサーバーにMisskeyの更新を通知する機能」は意図していないわね

[sakuhanight]

Misskeyという語について、ここではForkを含まない、ということですね？
(Forkを考えるときりがなくなるため？)

[tai-cha]

フォークをする時点でupstreamをチェックして追従するも追従せず独自の道を行くもそのリポジトリの管理者の責任かと…

[syuilo]

Misskeyという語について、ここではForkを含まない、ということですね？ (Forkを考えるときりがなくなるため？)

です

[syuilo]

(この場に限らず、自分が「Misskey」といった場合は「Misskey」を指しています(トートロジー🤯))

[sakuhanight]

そのリポジトリの管理者の責任かと…

とはいえ、upstreamで実装された場合にその機能をないものとするならば積極的に削除を行う必要があり、不親切です。

[tai-cha]

とはいえ、upstreamで実装された場合にその機能をないものとするならば積極的に削除を行う必要があり、不親切です。

不親切ではあるのは承知の上で、それでも実装が複雑になるコストが無視できないものな以上は妥協点を探すべきです（それによってmisskeyそのものの実装を複雑にする理由にはなり得ないと思います）

[syuilo]

MisskeyはMisskeyのために作られていて、Misskey派生ソフトのために作られているわけではない(し、Misskeyから派生したソフトウェアを作ってくださいとお願いしているわけでもない)から、しょうがないんじゃないかしら

[samunohito]

off-topic:
更新があることを知ってもらうための広報活動にパワーを割いた方が有益な気がしてきました

[tai-cha]

off-topic

更新があることを知ってもらうための広報活動にパワーを割いた方が有益な気がしてきました

その方法はこのIssue通りでなくてもよい（たとえば純粋にmisskey-dev/misskeyの最新バージョンを表示するようにするとか）

[syuilo]

あー、Purposeに書かなかったけど更新があることを知ってもらう目的もあるけど楽しそうという理由もあるわね

[tai-cha]

もしくは自動的にお知らせを表示する

楽しそうという理由もあるわね

バージョン比較によるアップデート通知ではなくmisskey-devからのお知らせ・メッセージ・おたよりみたいな機能でもいいのかもしれない

[syuilo]

ほむん
それは実装が難しそうだわね(自前のサーバーが必要になりそう)

[syuilo]

いや既にMisskey Hubがあるからできなくはないのか

[sakuhanight]

(ちなみにですが、GitHubのReleaseはRSSで取得できるため、熱心な運営者、Forkメンテナーはこれを見ることもできます)
楽しそうというモチベーションであれば、misskey-dev/misskeyに限った自動更新という部分にフォーカスするのがよいとおもいます。

[syuilo]

お知らせは別にした
#15090

[fruitriin]

更新の告知は良さそう

コンパネから更新ボタンは、仮に実現しようとすると 現状では最低でもgitの最新を取ってきてpnpm installとpnpm buildを実行する必要があり、misskeyの実行しているnode(を動かしているユーザー)よりも強い権限がないとできないことがあるので難しいかも？

[syuilo]

WordPressとかどういう実装になっているんだろう

[fruitriin]

なんかファイルダウンロードしてきて、rsync的なもので自分自身を書き換えてると思う

[sakuhanight]

WordPressとかはファイルの置き換えだけで終わりだから、実行ユーザーと所有者が同一なら何の問題も無くできるはず

[syuilo]

ほむん

[fruitriin]

Wordpressはめちゃくちゃ古いのでパッケージマネージャ的なものを使ってない（！）のでこんな芸当ができるけど、nodeアプリケーション全般で、バージョンに応じたnode_modulesがないと起動しないので、とても大変な予感

あとアプデに失敗したときにドウシヨウって話と、なんかよくわからないけどいじってた部分が消えちゃった！みたいな人のサポートがしぬほどだるそう

というのも込み込みで模索するなら、まあアリなのかな……？

[sakuhanight]

そういうこともあり、十分な検証は必要だろうと思います……(fork云々に限らず)

[catsmiry]

たしかCherryPickとかいうForkで実装されてたような気がする