SATYSFIの開発についての要望 金子尚樹 (@puripuri2100) SATYSFI Conf 2023 2023 年 10 月 22 日

1/8 概要 パッケージ作成者として以下の点について困っている バージョニングとリリースサイクル 開発方針の不透明さ

1/8 概要 パッケージ作成者として以下の点について困っている バージョニングとリリースサイクル 開発方針の不透明さ 以下、それぞれについて具体的に述べていく

2/8 バージョニングとリリースサイクルについて 2018 年の v0.0.1 から 5 年経っても v0.0.9 バグの修正と機能の追加が同じ粒度で行われているのがわかりにくい 0.0.9 の変更点は 0.0.8 にあったバグの修正だけ 0.0.8 ではなく 0.0.9 を使うべきなのだが伝わらない 本来は 1.8.1 などとするべき リリースサイクルがさすがに遅すぎる 0.0.9 にあったバグを修正するパッチは取り込まれたもののリリースされない satyrographos-repo の CI が落ちるので新しいパッケージも公開しにくい 新しい機能を提案してもそれを使って作ったパッケージを提供できるようにな るまで年単位で待たないといけない satysfi.0.0.9-6-ge0304803 のような「異常な」バージョニングに繋がる

3/8 過剰な後方互換性の保護 後方互換性が大事なのはわかるが、過剰すぎる そもそもとしてバージョンが 0.0.z 利用者としては「いつでも、いかなる変更も起こりえる」と思っている リリースサイクルの遅さと組み合わさると致命的 正直やってられない 例えば： clear-page プリミティブが多段組では命名通りの挙動をしていな いことについて修正を出しても取り込んでもらえない 多段組対応のクラスファイルをいつまでも運用できない 作ったはいいけど他人に使ってもらうことはできない セマンティックバージョニングがあるのだから破壊的変更をやっても良い （そのためのセマンティックバージョニング）

4/8 v0.1.0 について リリースが予告された状態で数年間お預け 開発者としてはどちらに注力していいのかわからない 「新しく作ってもどうせ使えなくなるんでしょ？」 そしてリリースがされない 0.1.0 の開発ブランチで動くものを維持し続けるのは大変 そして作ったとして誰が使うのか？ 予定されている機能が気が付いたら増えている F-ing modules だけでもいいから使いたい 内蔵パッケージマネージャは最優先事項ではない 縦組みと RTL は次の次の大型アップデートで別によい

5/8 リリースについての提案 リリースサイクルを早める 一定期間あいて、かつ変更があったらリリース 3 ヶ月とかで良い リリース作業が面倒なら自分がやります 0.0.z から脱出する 後方互換性を気にするなら 1.0.0 になってからにしてほしい せめて 0.y.z になってほしい 後方互換性の破壊を恐れすぎないでほしい 0.1.0 で予定されている機能をすぐにでもリリースしてほしい 使えるようにならない限りは何もできない

6/8 開発方針について どういう方針で開発が行われているのかがわからない gfn さんの個人開発ベースでやるのか、やる気のある人に権限をある程度渡 して一緒に進めていくか、すら未だによくわかっていない 機能追加の基準がわからない 「基本機能は最小に」という方針も曖昧な感じがある character 型の追加は渋られるが位置情報付き文字列型の追加はすぐに行われ ている プルリクエストを送りにくい 何が必要なのかもわかっていない テストは追加した方が良さそう、くらいしか自分もわからない プルリクエストは祈り、神託待ち状態

7/8 開発方針についての提案 一度言語化してほしい 個人開発なのか集団開発なのか 大まかなロードマップの共有 機能追加の基本方針 「優しい終身の独裁者」になるにしてもその前段階の指針は欲しい リリースサイクルの遅さは人手不足が一因にあるため、個人的には集団で ガシガシ進めてほしい気持ちがある

8/8 まとめ 議論や意見交換の場は閉会後に設けて居るのでぜひ この発表で言及した要望はこんな感じ： リリースサイクルを早めてほしい 0.0.z から脱出してバージョニングを適切にやってほしい 0.1.0 で予定されている機能をすぐにでもリリースしてほしい 開発方針やロードマップは提示してほしい 機能追加はドシドシやってほしい