Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
1 task
syuilo opened this issue Dec 3, 2024 · 57 comments
Open
1 task
Labels
✨Feature This adds/improves/enhances a feature

Comments

@syuilo
Copy link
Member

syuilo commented Dec 3, 2024

Summary

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

Purpose

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

Do you want to implement this feature yourself?

  • Yes, I will implement this by myself and send a pull request
@syuilo syuilo added the ✨Feature This adds/improves/enhances a feature label Dec 3, 2024
@samunohito
Copy link
Member

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

@syuilo
Copy link
Member Author

syuilo commented Dec 3, 2024

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

@sakuhanight
Copy link
Contributor

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

@anatawa12
Copy link
Member

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

@sakuhanight
Copy link
Contributor

🤯

@samunohito
Copy link
Member

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

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

@samunohito
Copy link
Member

samunohito commented Dec 3, 2024

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

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

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

@syuilo
Copy link
Member Author

syuilo commented Dec 3, 2024

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

@samunohito
Copy link
Member

うーーーーむ

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

//#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
Copy link
Member Author

syuilo commented Dec 3, 2024

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

@sakuhanight
Copy link
Contributor

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

@samunohito
Copy link
Member

samunohito commented Dec 3, 2024

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

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

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

@syuilo
Copy link
Member Author

syuilo commented Dec 3, 2024

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

@syuilo
Copy link
Member Author

syuilo commented Dec 3, 2024

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

@syuilo
Copy link
Member Author

syuilo commented Dec 3, 2024

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

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

@syuilo
Copy link
Member Author

syuilo commented Dec 3, 2024

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

@eternal-flame-AD
Copy link
Contributor

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

@sakuhanight
Copy link
Contributor

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

@syuilo
Copy link
Member Author

syuilo commented Dec 3, 2024

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

@sakuhanight
Copy link
Contributor

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

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

@syuilo
Copy link
Member Author

syuilo commented Dec 3, 2024

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

@sakuhanight
Copy link
Contributor

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

@eternal-flame-AD
Copy link
Contributor

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

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

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

@sakuhanight
Copy link
Contributor

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

@samunohito
Copy link
Member

samunohito commented Dec 3, 2024

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

@sakuhanight
Copy link
Contributor

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

@syuilo
Copy link
Member Author

syuilo commented Dec 3, 2024

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

@samunohito
Copy link
Member

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

@syuilo
Copy link
Member Author

syuilo commented Dec 3, 2024

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

@sakuhanight
Copy link
Contributor

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

@samunohito
Copy link
Member

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

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

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

@syuilo
Copy link
Member Author

syuilo commented Dec 3, 2024

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

@sakuhanight
Copy link
Contributor

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

@tai-cha
Copy link
Contributor

tai-cha commented Dec 3, 2024

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

@syuilo
Copy link
Member Author

syuilo commented Dec 3, 2024

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

です

@syuilo
Copy link
Member Author

syuilo commented Dec 3, 2024

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

@sakuhanight
Copy link
Contributor

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

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

@tai-cha
Copy link
Contributor

tai-cha commented Dec 3, 2024

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

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

@syuilo
Copy link
Member Author

syuilo commented Dec 3, 2024

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

@samunohito
Copy link
Member

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

@tai-cha
Copy link
Contributor

tai-cha commented Dec 3, 2024

off-topic

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

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

@syuilo
Copy link
Member Author

syuilo commented Dec 3, 2024

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

@tai-cha
Copy link
Contributor

tai-cha commented Dec 3, 2024

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

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

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

@syuilo
Copy link
Member Author

syuilo commented Dec 3, 2024

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

@syuilo
Copy link
Member Author

syuilo commented Dec 3, 2024

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

@tai-cha

This comment has been minimized.

@sakuhanight
Copy link
Contributor

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

@syuilo
Copy link
Member Author

syuilo commented Dec 3, 2024

お知らせは別にした
#15090

@fruitriin
Copy link
Contributor

fruitriin commented Dec 3, 2024

更新の告知は良さそう

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

@syuilo
Copy link
Member Author

syuilo commented Dec 3, 2024

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

@fruitriin
Copy link
Contributor

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

@sakuhanight
Copy link
Contributor

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

@syuilo
Copy link
Member Author

syuilo commented Dec 3, 2024

ほむん

@fruitriin
Copy link
Contributor

fruitriin commented Dec 3, 2024

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

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

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

@sakuhanight
Copy link
Contributor

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

@catsmiry
Copy link

catsmiry commented Dec 8, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
✨Feature This adds/improves/enhances a feature
Projects
Development

No branches or pull requests

8 participants