sakura
sakura copied to clipboard
sakura-editor
次回リリースのバージョン番号の決定
内容
次回リリースのバージョン番号を決めたいです。
参考
今のところリリースされている最新バージョンは 2.3.2.0 です。
https://sourceforge.net/projects/sakura-editor/files/sakura2/
- 2.3.2.0 ... 2017-05-02
- 2.3.1.0 ... 2016-08-14
- 2.3.0.0 ... 2015-10-12
次バージョンのリリース時期・内容
パッケージングの仕組みがうまく動くようになった段階でリリースするくらいの感覚で考えています。時期としては6月末くらい……かな、と（個人的な感覚です）。
次バージョン番号の検討材料
- 機能的に大きな変更は入らないと考えています。そういう意味では 2.3.3.0 くらいでも良いかも。
- GitHub 移行を大きな変更と捉え、2.4.0.0 にするという選択もあります。
これまでのリリース時期とバージョン番号の決定ポリシーについて
これまでにバージョン番号やリリース時期はどのように決められていたのか、ポリシー等分かる方いらっしゃいましたら情報いただきたいです。
2.3.3に1票です。
GitHub移行は大きな転機と思いますが、実はまだ何もしてないので2.4じゃない気がします。
過去はその時々のコミッタさんが独断で決めてたように見えました。一度だけ、どうします？って見たけどあの後にリリースはなかった気がします…
げんたさん時代は…というか3年前以前のことはよく知らんです。
機能的に大きな変更は入らないと考えています。そういう意味では 2.3.3.0 くらいでも良いかも。
2.3.3.0 のバージョンには反対です。
また、ユーザーから見たときに特に更新したいと思う修正が 入っていない状態でのリリースにも反対です。
FFFTP が更新されてない状態が続いて、久しぶりに更新されたタイミングで 窓の社で記事になりました。 https://forest.watch.impress.co.jp/docs/news/1115458.html
もし、sakura editor が 2017-05-02 から一年ぶりにリリースされた場合 同様にフリーソフトウェア関連のサイトで記事になるかもしれません。 (更新されなかった期間に違いはありますが)
そのとき 2.3.2.0 → 2.3.3.0 になりました、では記事も書きにくいし 更新したいとユーザーも少なくなると思います。
一般にリリースするのであれば、ユーザーから見たときに更新したくなる修正がほしいです。 そんなに技術的に難しくなくてユーザーから見たときのインパクトのある修正は64bit 対応 だと思います。
これまで 32bit 版だと編集できなったファイル(すごく大きなログファイルなど)が 編集できるようになります。
64bit 対応が思ったより時間がかかるということであれば 公式に Windows 10 に対応します、というのでもいいと思います。 http://proengineer.internous.co.jp/content/columnfeature/5319
バージョン番号の上げ方は決まったルールはないような気がします。 ここで決めてしまうのもいいかもですね。 バージョン：ソフト的に大きな変更がある場合（Ansi->Unicodeとか32Bit->64bitでもここあげる？) リビジョン：新機能等の追加等 ３桁目（なんていうの？）：ソフトによりますが、この桁でバグフィックス対応ほか軽微な修正、パッチ的な修正。 ４桁目（なんていうの？）：パッケージングしなおし、プログラム以外の付帯物の修正追加
こんな感じですかね。 で、次をどうするかですが、OSSそのものに対して確かに何か大きなインパクトがあるわけではないので、@berryzplus さんの言われることは激しく同意なのですが、GitHub移行後の初めてのパッケージングはソフト本体は延長線上であるものの新しいアーキテクチャでこしらえた新しいパッケージであることを外部に意思表示するいみではリビジョンをあげるのもいいのかなと。 @m-tmatma さん言われるように何か目玉な機能はほしい気もしますけれども。 もう一つの味方としては、切れ目なくこれからも修正しつづけてるんですよってことで、単に４桁目か３桁目だけ上げた版をさらりとリリースするって考え方もありますね。
すいません。どっちやねんって感じになりました。
最初に書いた2.3.3.0への同意は、6末リリース前提では新機能までは行かないだろうとの読みから出たものです。せっかくリリースするなら更新するだけの付加価値を付けるべきの意見には賛同します。
タイミングはおそらくnowがベターです。
入れれば確実に付加価値となるような何かを6末リリースに間に合うように選定してみてはどうでしょう。この一年の累積修正もカウントしていいと思います。
2.3.2.0 (2017-05-02) から今の時点までのログを以下に載せました。 https://github.com/sakura-editor/sakura/wiki/NextRelease
ざっと見た感じ、主な変更はバグ修正くらいで、これといった追加機能は無いですね。 たしかに目玉機能は欲しいと思いました。
ところで、2015-02-25 の以下の記事の中で 老舗テキストエディター「サクラエディタ」v2.2.0.0が公開、ミニマップ機能などを追加 - 窓の杜
オープンソースの老舗テキストエディター「サクラエディタ」の最新版v2.2.0.0が、22日に公開された。64bit版を含むWindows 2000/XP/Vista/7/8に対応するフリーソフトで、編集部にてWindows 8.1で動作を確認した。
と書かれているのですが、書きぶりだけ見ると公式が 64bit 版を配布していたように読めなくもないのですが、そういう事実ってありましたっけ。
@kobake さん、おそらく、「64bit版もあるよっていってるだけ」で正式にリリースしたってことはいってないのかなと。 聞屋さんは事実を嘘ではない範囲で（たまに嘘もあるけど）さもどうとでも取れるような書き方はよくします。
なるほど・・・(´Д｀)
では 64bit 版を公式配布すること自体はおそらく初めてのはずで、インパクトはあると考えることにします。64bit 対応以外に次回リリースで入れたい機能ってありますか？＞all
私も可能なら2.4.0.0でリリースした方が話題にもなって良いかなと思います。
今後大規模な破壊的変更を行う予定があるなら、「旧体制の最終安定版」みたいなリリースがあってもいいかなと思ったり。
しかし、実際の利用者は破壊的変更を求めてない気もするので、次のリリース時に要望の投票とか、Google Formsのアンケートとかで利用者の声を集めて見るのも良いかもしれませんね・・・
しかし、実際の利用者は破壊的変更を求めてない気もするので、次のリリース時に要望の投票とか、Google Formsのアンケートとかで利用者の声を集めて見るのも良いかもしれませんね・・・
google form でアンケートを作ったことがないので試しに作ってみました。https://goo.gl/forms/M2ITr7oW4q0W4xnH3
すごく簡単に作れます。
@KageShiron さん
しかし、実際の利用者は破壊的変更を求めてない気もするので、
たぶん…いや、絶対そうだと思ってます。
ある変更が破壊的なものでないと証明する手段がないってのは困ったことです。 （手段がないからできません、じゃ意味無いんですが... :smile: ）
@m-tmatma さん
すごく簡単に作れます。
アンケートは「聞きたい人」が「答えてもいい人」に向けるメッセージなんだそうです。 答えやすい設問を作るのは結構難しいです。 設問作るの得意な人がいたらすごく助かる感じです。
64bitOSで動かした時、たまに起動が重たくなる事象に対する暫定対応というのを週末にPR予定です。
この件、「暫定」でも修正量が多いので間に合わない気がしてきました。 詳細は今夜、別issueで。
アンケート良いですね。次リリースバージョンの初回起動時だけアンケート促すダイアログとか入れたいなーと思いました（うざいですかね。一度起動だけなら良いかな、と）。
あと、ヘルプメニューから「GitHub Issues」「アンケート」に直接飛べるリンク張りたいな、と思っています。
アンケート良いですね。次リリースバージョンの初回起動時だけアンケート促すダイアログとか入れたいなーと思いました（うざいですかね。一度起動だけなら良いかな、と）。
前にあった「緊急事態向けに CDROM に入れて携行」な用途では 初回起動時に出しちゃうとちゃぶ台返しされそうな感じですね・・・ 情報収集量の期待値は減りますが、インストーラの完了画面にボタンorリンクが無難かと。
あとは「ご利用に関するアンケートへのご協力をお願いしています。ご協力いただけますか？」をチェックさせるのもいいかも知れません。言質をとったら最期、あとはやりたい放題です。 当然、デフォルト選択は「はい」:smile:
あと、ヘルプメニューから「GitHub Issues」「アンケート」に直接飛べるリンク張りたいな、と思っています。
#74 の話題と統合できるとかっこよさそうです。 近年のvisual studioに搭載されてる評価機構はよくできてますよね。 あんな感じ・・・
アンケート良いですね。次リリースバージョンの初回起動時だけアンケート促すダイアログとか入れたいなーと思いました（うざいですかね。一度起動だけなら良いかな、と）。
うざいと思います。 iPhone アプリでは、レビューを要求するアプリは結構ありますが、 Windows アプリではほとんどないです。
メニューからユーザーが自分で選んで、アンケートに記載するのは問題ないと思います。
あと、ヘルプメニューから「GitHub Issues」「アンケート」に直接飛べるリンク張りたいな、と思っています。
いいと思います。 ただアンケートは、アンケートの URL が変わったら面倒なので 直リンクではなくweb site のどこかにしたほうがいいと思います。
別件ですが、アップデートがあったときの自動更新があれば嬉しいと思います。
純粋な機能要求だと、閉じタグ(言語依存だと、{[enter]で、}が下の行に挿入されるとか、< pre >[enter]で</ pre >が挿入されるとか、try {[enter]で }catch{ }って挿入されるとか)自動挿入かなぁ。。。と呟やいてみる。 すいません、話がそれそうなのでこのへんで。
機能については PR に上がってきたものがあればガンガン吸収したいです。 自分のほうでもひとつ実装したい機能があるので近いうちに上げようかと。
自動更新
新しいバージョンのリリースを自動検知してステータスバーに表示するくらいが無難かな、と思いました。自動更新って「実装が大変そう」かつ「自動更新されたくないユーザも多そう」なので。
誰も書いてないけど64bit公式対応・GitHub移行・自動更新がセットならいっそ3.0でもいいのではと雑な発想…UNICODE対応と64bit公式対応は同等ぐらいの認識があったので。
更新通知と自動更新両方を楽に実装するならChocoletty呼び出して検知するのが楽？ 推奨インストール方法をChocolettyにしちゃうことになるのが微妙な気もするけど、SakuradownだとUACひっかかっちゃうからなぁ。（Sakuradownまるっと本体に取り込めると理想ではある
質問項目は難しいですね。 個人的には他にもエディタがある中で、なぜサクラエディタを使い続けるのかが重要ポイントだと思うので、そこを確認したいです。あまり高度な設定を入れても逆に混乱するという人もいるでしょうし、非プログラマ向け機能の需要があるかもしれません。
Google Forms以外に、Twitterハッシュタグで改善点を呟こう！ぐらいがカジュアルに集めやすいのかもしれません。
自動更新
Chocolateyは色々あれなので、非エンジニアにまで勧めたいかというと・・・:thinking: いっそ、ストア登録を目指すのはありかもしれません。ちょうど新しい形式のインストーラが出たので微妙なタイミングではありますが・・・ http://www.itmedia.co.jp/pcuser/articles/1806/07/news110.html
個人的に他の要望としては
- 標準UTF-8化(指定しなければSJISで保存しない)
- 外部ヘルプの類にURLを指定可能にする
- 設定項目の見直し。VisualStudioのようにタブではなくツリーで設定画面を切り替えるとか、マニアックな項目は上級設定の中や設定ファイルをいじってもらうようにするなど。
Twitterハッシュタグ良いと思います。活発に使われるのであればTwitterハッシュタグの検索結果をトップページに埋め込むと良いかも。
標準UTF-8化、対応したいです。 ストアは……UWP形式にしないと配布できないという認識でしたがどうでしたっけ……。 設定画面もそろそろ整理したいですね。ツリーにするのに加えて検索ボックスを付けられるとかなり利便性上がると思います。
SakuraDown って誰がメンテしているのかって誰か分かりますか。
http://sakura.qp.land.to/?Install%2FSakuraDown ここ見ると最後に修正したのは、
.NET Ver1.3.x alphaがダウンロードできないため、Ver1.2f-18でダウンロードできるように対応しました。 -- novice? 2017-08-22 (火) 02:40:39
noviceさんですかね。 ソースも同封されてるので誰でも直せるって感じなのかもしれませんね。 確かに私でも直せそうです。
Wikiのところにバイナリー公開されていないようですが、ヒストリーに、
.NET Ver1.3.x alpha VB2005.NET移植版。sakura2.x版のみ提供。
っての記載がありますね。はて。。。？？？
なんか話が進んでるようで
Chocolateyは色々あれなので、非エンジニアにまで勧めたいかというと
そうですよね…
あと一晩寝てから気がついたのですがそもそもインストーラにSakuradownで拾ってくるファイル全部同梱できるならそれで済むんですよね。その場合単にインストーラで上書きインストールだけで済むしUACの問題も無くなるので。自動更新はいろいろ面倒なのでサクラエディタ側では常駐にポップアップの更新通知（クリックすると公式サイトに飛ぶ感じ？）だけでやりたい人がChocolatey等使えばいい話かなと…
@berryzplus さん
64bitOSで動かした時、たまに起動が重たくなる事象に対する暫定対応というのを週末にPR予定です。
これって何をする予定だったか、覚えてますか? 覚えているうちにチケットだけでも作っておいていただけますか?
これって何をする予定だったか、覚えてますか?
暫定策を提案するつもりでした。 そこをケアしても他の原因にも手を打たなければ遅延は解消しないのでやめました。
遅延の原因は3つあると見ています。 うち1つは着手済み(プロセス起動時の排他制御絡み)です。 うち1つはいずれ着手予定の初期表示時の同期制御絡みです。 最後の1つはまだ秘密です。大規模修正が必要なので、準備ができるまで内容は伏せときたいです。